For a couple of weeks now, I’ve got some reports about crashing datasheet views when using custom master pages. As a reminder, the datasheet view is a view you can select when browsing within a list. It’ll enable you to view and edit the list in an excell-like format. Quite handy for bulk changes.
So, what is happening? I noticed the page was going into an infinite loop. When debugging I stumbled upon the GC-functions. Those functions are located in core.js and control the resizing of the datasheet view control. After carefull reviewing, I noticed the document.documentElement.scrollHeight was growing and growing. It seemed that my custom master page let the scroll height go out of it bounds.
To fix this, I simply bound the scroll height to the client height. To accomplish this, you look for
in core.js and replace it with
var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ? document.documentElement.clientHeight : document.documentElement.scrollHeight;
This seemed to solve the problem and stopped the browser from crashing.
But why was this happenning? My best bet is the use of a specific doctype in my masterpage. In quirks mode, IE includes top and bottom borders and padding widths when calculating the offsetheight. Standard mode only defines the content height as offsetheight. I’m guessing core.js relies on the extra margins. Now, the strange thing is, the custom master pages of MOSS (BlueBand, OrangeSingleLevel, …) do not experience this bug, altough they also use a specific doctype. I didn’t really investigate into it too much, but I suspect they restrict the height of some container surrounding the main content. This could stop the growth of offsetheight. If anyone of you, readers, can confirm this behaviour, feel free to respond in the comments.
In the meantime.. have fun branding!
Update: according to reader Rufino, you can also revert this behaviour by specifying a height. Didn’t test it yet, but I’m pretty sure this ‘ll do the trick too. Thanks Rufino!