Horizontal scroll bar does not appear

This is about an issue that we had with our public facing web site master page. That the horizontal scroll bar does not show, when it should, that is, when the page width is bigger than that of the browser window displaying it. Interestingly, it comes when you scroll down to the bottom of the page.

I did not know that SharePoint 2010 implements the scroll bars with some JavaScript so they enclose the s4-workspace div, not the body element, including the “ribbon”. And we had the above issue because I did the master page in such a way that it does not have the ribbon when the pages are viewed by the visitors.

I am sure that it is a requirement for everybody who do their public facing sites on SharePoint 2010. We need to get rid of the ribbon when the pages are consumed, while we do need it when we prepare them.

At the very early stage (with SP2007), I achieved it by denying any write on the internet zone. The Sites Action menu was not presented, if I remember well. Then soon enough, I needed to come up a different mechanism, because the site does need to be writable in certain cases such as a feedback form. I wrote a control, and with which I enclose the ribbon so that the ribbon is not rendered on the internet zone. This “not rendered” was the cause of the issue.

It appears that when SharePoint JavaScript displays the horizontal scroll bar at the bottom of the window, it positions it vertically from the ribbon. Therefore, when it does not find the ribbon, the starting point, it displays it only at the very bottom of the page, where s4-workspace div ends.

I have overcome it by hiding the ribbon i.e. style="display:none;" rather than being not rendered.

Hope it helps.

References:
- Starter Master Page: http://archive.msdn.microsoft.com/odcSP14StarterMaster
- A useful JavaScript trick: http://blog.pixelmill.com/944/sharepoint-2010-%E2%80%93-adding-a-fixed-footer-to-your-sharepoint-master-page/

CSS delivered as Content-type: application/octet-stream

I do not know if this could ever be any benefit of anybody. It could be just that there is something wrong with our servers…

On our site, sometimes (it appears) CSS files are delivered to clients as Content-type set to application/octet-stream.

The story starts as a few colleagues report pages are displayed ugly without styles on Firefox and Chrome. OK on IE.

I found that the CSS is stored in the browser's cache as application/octet-stream. This is tricky because once you clear the cache and go to the page again, the CSS would be downloaded OK.

There seems nobody having similar issue, or at least reporting to the net. I tried to come up with an own workaround.

I wrote an HttpModule to verify if responses for css files are generated correctly as Content-type: text/css, and correct it if not. It writes into the log file each time it find such a problematic response. By the way, in the course of writing the module and testing it, I found that IE applies styles even if it receives the css file as application/octet-stream. This is why the problem has been reported happening only on Firefox and Chrome. Furthermore, for some css, those that SharePoint generates, you can change the Content-type (to application/octet-stream for the testing) in the MIME type configuration of IIS. However, those of our own creation, those in the /Style library folder, come as text/css, even after the change in the IIS’s MIME section. So it is SharePoint that controls it.

Towards the end of the first day after the module is plugged in, the module reported that it did the Content-type correction. And a lot! We have two Web Front End in a farm. Both connect to one single Content database. Each web server generates those mal formed css responses at different timings.

Each has a IISRESET scheduled job. At different times of a day, obviously. Each generates the problematic responses after the IISRESET and stops doing so when the application pool gets recycled. (it gets recycled when the memory usage reaches the threshold)

Sh*t!! I should have requested pages from the server while the module there was reporting the problem!! I could have verified that my Content-type correction does the trick. No worries. It would come again, I guess…