SharePoint Branding Issues: Edit In Datasheet View
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
var lGCWindowHeight=document.documentElement.scrollHeight;
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!
July 28th, 2008 at 18:07
Try specyfing a css sytle in your custom masterpage
html, body
{
margin:0;
padding:0;
height:100%
border:none;
}
That way you don’t have to modify the core.js
–>Rufino
October 6th, 2008 at 12:30
[...] Josh Gaffey’s Blog [...]
October 11th, 2008 at 2:20
[...] public links >> masterpages SharePoint Branding Issues: Edit In Datasheet View Saved by Luffy90 on Thu 09-10-2008 Unity IoC and ASP.NET Part II Screencast with Appearances by [...]
November 3rd, 2008 at 11:15
[...] – bookmarked by 5 members originally found by amott1973 on 2008-10-14 SharePoint Branding Issues: Edit In Datasheet View http://tomblog.insomniacminds.com/2008/07/23/sharepoint-branding-issues-edit-in-datasheet-view/ – [...]
December 11th, 2008 at 20:16
I’d like to comment that Rufino Virata’s suggested fix did not work for me, however the suggested change to CORE.JS did in fact solve the problem.
I noticed on other sites they talk about removing the DOCTYPE, which does work, but we all know that having a page without a DOCTYPE is a no-no. =)
Thanks for this post, btw. It solved much, MUCH pain and suffering.
Cheers.
January 18th, 2009 at 13:21
Hi,
Thanks for the post
Regards,
January 28th, 2009 at 18:34
You can override the function from Core.js in your custom master pages. This way you don’t have to remove the doctype or mess with core.js.
function GCComputeSizing(GCObject)
{
if (TestGCObject(GCObject))
{
var fBIDI=(document.documentElement.currentStyle.direction==”rtl”);
var lGCWindowWidth=document.documentElement.scrollWidth;
var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ? document.documentElement.clientHeight : document.documentElement.scrollHeight;
var lGCObjectOffsetLeft=0;
var lGCObjectOffsetTop=0;
if (fBIDI)
{
lGCObjectOffsetLeft=-180;
lGCObjectOffsetTop=120;
}
else
{
lGCObjectOffsetLeft=32;
lGCObjectOffsetTop=-2;
}
var lGCObjectWalker=GCObject.parentElement;
while (lGCObjectWalker !=document.body)
{
lGCObjectOffsetLeft+=lGCObjectWalker.offsetLeft;
lGCObjectOffsetTop+=lGCObjectWalker.offsetTop;
lGCObjectWalker=lGCObjectWalker.offsetParent;
if (fBIDI)
if (lGCObjectWalker.offsetLeft > 0)
break;
}
lGCObjectOffsetLeft+=GCObject.parentElement.offsetLeft;
lGCObjectOffsetTop+=GCObject.parentElement.offsetTop;
glGCObjectHeight=lGCWindowHeight – lGCObjectOffsetTop;
if (glGCObjectHeight > lGCWindowHeight)
glGCObjectHeight=lGCWindowHeight
if (glGCObjectHeight lGCWindowWidth)
glGCObjectWidth=lGCWindowWidth;
if (glGCObjectWidth < cGCMinimumWidth)
glGCObjectWidth=cGCMinimumWidth;
}
}
February 4th, 2009 at 11:47
Thank you very much for posting this fix – very useful.
February 4th, 2009 at 15:41
You stated:
“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”
With my testing, I’ve found that the conditions needed to reproduce this issue are:
1. You are using a custom master page and have specified a DOCTYPE
2. You have images or spacing in the footer area (or anywhere underneath the main content area) that specify a height. This also includes class styles with a height setting on any element in this region.
The custom master pages that come with MOSS don’t have images or spacing in the footer area. That’s the difference.
BTW, it’s a great idea to override the offending method instead of modifying the CORE.js file, as Joyce says. However, the overridden method above has a typo. Here’s the fixed one (unless your formatter screws it up):
function GCComputeSizing(GCObject)
{
if (TestGCObject(GCObject))
{
var fBIDI=(document.documentElement.currentStyle.direction==”rtl”);
var lGCWindowWidth=document.documentElement.scrollWidth;
var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ? document.documentElement.clientHeight : document.documentElement.scrollHeight;
var lGCObjectOffsetLeft=0;
var lGCObjectOffsetTop=0;
if (fBIDI)
{
lGCObjectOffsetLeft=-180;
lGCObjectOffsetTop=120;
}
else
{
lGCObjectOffsetLeft=32;
lGCObjectOffsetTop=-2;
}
var lGCObjectWalker=GCObject.parentElement;
while (lGCObjectWalker !=document.body)
{
lGCObjectOffsetLeft+=lGCObjectWalker.offsetLeft;
lGCObjectOffsetTop+=lGCObjectWalker.offsetTop;
lGCObjectWalker=lGCObjectWalker.offsetParent;
if (fBIDI)
if (lGCObjectWalker.offsetLeft > 0)
break;
}
lGCObjectOffsetLeft+=GCObject.parentElement.offsetLeft;
lGCObjectOffsetTop+=GCObject.parentElement.offsetTop;
glGCObjectHeight=lGCWindowHeight – lGCObjectOffsetTop;
if (glGCObjectHeight > lGCWindowHeight)
glGCObjectHeight=lGCWindowHeight
if (glGCObjectHeight lGCWindowWidth)
glGCObjectWidth=lGCWindowWidth;
if (glGCObjectWidth < cGCMinimumWidth)
glGCObjectWidth=cGCMinimumWidth;
}
}
Joel
February 4th, 2009 at 23:48
Thanks Joel and Joyce for your input.
Joel> I also discovered your findings some time ago. Unfortunately it didn’t really help me to get a full fix. Why? Well, this javascript fix does not work in IE6. IE7 appears to be handling the workaround just fine. IE6 on the other hand still gives me trouble.
So if anyone knows something more, just leave a comment.
February 16th, 2009 at 5:50
I have a blue band master page that I have customized, I had a footer with style and height specified, I was receiving errors when trying to open in Data Sheet view until I deleted the cell height of the footer. I can now open in Data Sheet view as long as I am using an XP machine with IE7, however if using a Vista machine with IE7 the open in Data Sheet view looks up IE. Anyone have any suggestions?
March 2nd, 2009 at 15:10
Hey everyone
Just to let you know i found a solution that works for me.If you have a left Nav that always has a height, (There are better ways) in the head of the master page add. Might not work for everyone.Sry.