Sharepoint Edit in Datasheet locks or freezes Internet Explorer

I ran into an interesting issue in Sharepoint 2007 last week that took me a few hours to solve and was not easy to debug.  I couldn't find any info on it anywhere so I thought this would be a good candidate for my first post to this blog.

One of my customers reported that when they tried to use the "Edit in Datasheet" view on any list in Sharepoint 2007 their computer would lock.  When I went to take a look at this I found IE was locked and it was consuming 50%+ processor time.  I also noticed that they were using a custom system master page which was the key to this problem.

After digging at the problem for an hour or so I found a margin style tag on the body tag of the master page. 


<body onload="javascript_spBodyOnLoadWrapper();" style="background-color: #5f9fd7; margin: 10px 10px 10px 10px;">

Suspecting that this might be part of the issue I removed this piece from the body tag and removed the custom style sheets they had inserted as well. This did fix the issue but now all my styles were gone.  When I added the custom style sheets back in the problem came back.  Still suspecting the margin issue I looked for margin tags in the style sheets.  I found one in a class called footer which, you guessed it, was a margin for the bottom of the page.  After removing this style the Edit in Datasheet feature worked without a problem, and I still had my custom master page and styles.

So, if Edit in Datasheet isn't working for you or it is causing excessive processor usage from IE, and you are using a custom master page, check for margin tags and remove them.

Comments (12)
  1. says:

    I find that the datasheet view is probamatic.  For instance I have a look up field in a table and it works fine in the normal NEW, EDIT and DISPLAY forms, but in datasheet view it gives that custom lookup field a prefix of string;# .  No one including guys I know at Microsoft know what causes this.  My team just puts up with it hoping it is a bug.

  2. shane says:

    Any other Ideas on how to fix this problem? I went through the custom style sheet and removed all margin calls, to no avail. I then set the page to use the default.master and included the custom style sheets on that and it worked fine, so I think it’s actually the custom master and not the style sheet. Any thoughts on where to look for the problem? Thanks for your time!!!

  3. Beatriz says:

    This should be one of the nicest features of SharePoint, it is very frustrating that it doesn’t work. Instructions from Microsoft on how to fix this would be greatly appreciated

  4. says:

    Margins wasn’t the problem for me, it was a Spacer I put in the Footer of my page.

    Original code on how to customize my page was off of the net "Microsoft Office Sharepoint Server 2007 – Custom Chrome/Branding"

    Not Working Code

    <tr><td class="my-spacer10"></td></tr>

    <tr><td class="my-footer">Copyright (C) 2008   Perrigo Internal Communications</td></tr>

    <tr><td class="my-spacer10"></td></tr>

    Working Code

    <tr><td class="my-footer">Copyright (C) 2008   Perrigo Internal Communications</td></tr>

    My-Spacer10 Class



    height: 10px;


  5. Ben says:

    Thanks for the suggestion. Why on earth would the margin tag make a difference? And any thoughts on why some might experience this issue and not others?

  6. Joel Hulen says:

    I found that there is a set of conditions that causes this lock-up:

    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 problem is NOT margin settings in your style sheet or page. Believe me, I have tested this thoroughly. The problem lies within the CORE.js file. I have applied the below fix and placed all my styles (including margin and size settings) back into my style sheets with no issues.

    So, what’s causing this to happen? There is a javascript function (located in the core.js file) that gets called by the datasheet view control when activated (GCComputeSizing(GCObject)) that sizes the datasheet element according to the current window size. Specifically, the culprit was "var lGCWindowHeight=documentElement.scrollHeight". This caused the scroll height for the page to go out of bounds. In quirks mode, IE includes the top & bottom borders within the padding widths when calculating the offsetHeight. Standards mode only defines the content height as the offsetHeight.

    To fix, I replaced the line:

         var lGCWindowHeight=document.documentElement.scrollHeight;


       var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ?  document.documentElement.clientHeight : document.documentElement.scrollHeight;

    This bounds the scroll height to the client height.

    I didn’t want to modify the CORE.js file, so within my master page, I override the method. To do this, paste the following within your master page (I stuck mine at the bottom of the page):

    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)










    var lGCObjectWalker=GCObject.parentElement;

    while (lGCObjectWalker !=document.body)





    if (fBIDI)

    if (lGCObjectWalker.offsetLeft > 0)





    glGCObjectHeight=lGCWindowHeight – lGCObjectOffsetTop;

    if (glGCObjectHeight > lGCWindowHeight)


    if (glGCObjectHeight < cGCMinimumHeight)


    if (fBIDI)





    glGCObjectWidth=lGCWindowWidth – lGCObjectOffsetLeft;

    if (glGCObjectWidth > lGCWindowWidth)


    if (glGCObjectWidth < cGCMinimumWidth)




  7. frank3nst31n says:

    Thanks for the suggestion, removing the doctype worked like a charm

  8. Reet says:

    Your are a star!! you saved me hours of Hard work. thank you so much…

  9. kiwibjs says:

    Thanks for the suggestions.  Removing the DOCTYPE worked for me too.  

    I also compared our master page with the Microsoft default.master and noticed that Microsoft don't specify a DOCTYPE in their master page.  Curious.  

    Thanks again!  You really got me out of a hole with a client.

  10. John Larsen says:

    I found setting a css max-height for the web part holding the list did the job.

Comments are closed.

Skip to main content