SharePoint and Chrome

Slalom Consultant Maarten Sundman

Slalom Consultant Maarten Sundman specializes in .NET, SharePoint, and Silverlight solutions and has experience in the Financial Services, Software, and Utilities and Energy sectors.

A few months ago I posted an entry called SharePoint 2010 Scrolling detailing a method to get scrolling working on less supported browsers in SharePoint 2010. Along with some background on to why the method works.

I’ve had reason recently to revisit Chrome and SharePoint compatibility specifically as of late. In the process a different fix came out of it. One that is less heavy-handed. But more importantly I found out that the cause of the scrolling inconsistency on some browsers like iOS Safari and Chrome is not due to the causes that have been previously documented by other bloggers or myself. The cause is, in fact, a timing issue around execution of a specific bit of very important onload JavaScript.

The bit that doesn’t execute (and causes a systemic issue, one of the issues it causes is the scrolling weirdness), is:

body onload=”if(typeof(_spBodyOnLoadWrapper) != ‘undefined’; _spBodyOnLoadWrapper();”

What this line means is basically if the page has loaded the onloadwrapper function from init.js. This onloadwrapper does a bunch of things, such as loading the ECMAScript for support SP.JS, executes page JavaScript for any onload events, and any client interactivity. Basically when this doesn’t execute pretty much no client side code from SharePoint can or will work, or any script that you have that relies on any of it. Scrolling is just the tip of the ice berg. Now for the good news, it’s easy to fix (I have a case in with Microsoft to look at including the fix in a future cumulative update).

Lastly, before showing the work around…SharePoint is not the only site affected by this issue, if you have a site loading JavaScript dynamically or via lazy loading and within that JavaScript have defined an OnLoad function, you can also run in to this issue.

$(document).ready(function()
{
Reinit();
});

function Reinit()
{
//verify we have finished loading init.js
if(typeof(_spBodyOnLoadWrapper) != ‘undefined’)
{
//verify we have not already initialized the onload wrapper
if(_spBodyOnloadCalled == false)
{
//initialize onload functions
_spBodyOnLoadWrapper();
}
}
//wait for 10ms and try again if init.js has not been loaded
else
{
InitTimer();
}
}

function InitTimer()
{
setTimeout(Reinit,10);
}

3 Responses to SharePoint and Chrome

  1. JB says:

    Thanks for the post Maarten. A lot of code posted for this fix does not include a test to see if onLoad has already been called – not good.

    Minor issue in your code though: should be a capital L on _spBodyOnLoadCalled – otherwise ‘not defined’ error will throw.

  2. Maarten Sundman says:

    That’s what the _spBodyOnLoadCalled check is for, is to verify that onLoad hasn’t already happened. If you look in SharePoint’s init.js it’s the first thing done within the onload function (before any actual work has been done), so it’s pretty reliable even if the onload function is in the middle of executing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: