SharePoint and Chrome


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.

So, 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. So 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);
}

  1. #1 by dotnetrevolution on September 13, 2012 - 2:48 am

    Hi,
    thanks for your post. Can you explain me where i can put this fix.

    Thanks for your answer.

    • #2 by Maarten on October 5, 2012 - 5:31 pm

      Most effective spot is within your master page. Or you can just add it within a content editor, however it would only fix pages containing the content editor.

  2. #3 by Dewey Vozel on November 5, 2012 - 12:38 pm

    Good article and with the changes below it does easily fix the vertical scrolling but I’m also having a huge problem with any content in the s4-workspace that is set to 100% width being layout out at 15618px in Chrome. Any idea how to stop that?

    if (typeof _spBodyOnLoadWrapper !== ‘undefined’) {
    if (typeof _spBodyOnloadCalled === ‘undefined’ || _spBodyOnloadCalled == false) {
    _spBodyOnLoadWrapper();
    }
    }

    • #4 by Maarten on November 7, 2012 - 12:01 pm

      I haven’t seen that behavior. I’d use developer tools to find out what is causing the page width to be read as 15,618px. However, using jquery you could modify it after the _spBodyOnLoadWrapper(); with:

      $(‘#s4-workspace’).width($(window).width());

  3. #5 by Olly Hodgson on November 9, 2012 - 5:13 am

    Thanks Maarten, this is brilliant!

    I found a typo though: Chrome kept complaining _spBodyOnloadCalled was undefined. It took me ages to notice the lowercase “L” in “Onload”. It should be an uppercase “L”, i.e. _spBodyOnLoadCalled. With that fixed, it worked perfectly!

  4. #6 by chris on November 11, 2012 - 7:44 pm

    hi marteen
    the fix seems to work, but i have to take out the code where it’s checking for _spBodyOnloadCalled as it keeps on giving me an error Uncaught ReferenceError: _spBodyOnloadCalled is not defined. just wondering what will happen if you execute _spBodyOnLoadWrapper twice

  5. #7 by Ali Robertson on December 6, 2012 - 5:59 am

    Chris, Marteen. Thanks for finding this issue! Here’s my version of this fix: https://gist.github.com/4224245 – Feel free to change it around in github or post it back here. I had to fix a letter case issue in your code: “OnloadCalled” should be “OnLoadCalled”. I also optimised it and made sure it only ran in Webkit

  6. #8 by eyal on December 19, 2012 - 2:04 am

    Hey Marteen,

    thanks for this, saved me much debugging time!

  7. #9 by sonya on February 11, 2013 - 6:47 am

    Hi Marteen
    I have found that this Function stops users adding web parts in edit mode. Add web part section of the ribbon does not appear.

    • #10 by Maarten on February 11, 2013 - 10:04 am

      Any javascript errors? If you’re getting issues with the ribbon and web parts then the function didn’t execute.

  8. #11 by sonya on February 11, 2013 - 12:04 pm

    Hi Maarten
    Thanks for replying so quick.
    TBH I have quite a lot going on in my masterpage. Jquery that’s changing css and I have a flexslider running too.
    I’ve put your function just inside the tag.

    It was one of my users that discovered they couldn’t add web parts. Nothing happens – they click on ‘Add a Web Part’ and the ribbon does not drop down to open the Web parts. Rolling over the Add a Web Part text just shows javascript: in the browser status bar. There are no errors.

    • #12 by Maarten on February 11, 2013 - 1:33 pm

      Hit F12 and go to the console view of the developer tools, you should see status messages there that will give you more insight as to what’s occurring. If add a web part and the ribbon are not working then ‘_spBodyOnLoadWrapper();’ is not being executed. You can also manually put that command in to and test.

      • #13 by Steve on March 15, 2013 - 6:20 pm

        Getting same error as well on a Sharepoint online 2010 publishing site. Error seems to only happen with my custom master page on a publishing site, works fine when my master page is applied to a team site.

        • #14 by Maarten on March 15, 2013 - 11:07 pm

          I would use firebug or ie developer tools to see what’s causing the error. Is jQuery loaded on the page?

          • #15 by Steve on March 16, 2013 - 12:29 pm

            No errors showing up in dev tools in IE or Chrome, just seems like javascript isnt launching on click.

          • #16 by Maarten on March 16, 2013 - 1:31 pm

            It shouldn’t execute on click, this JavaScript is for page load. Did you change the script around?

          • #17 by Steve on March 16, 2013 - 12:34 pm

            Also, yes I have the latest jQuery loaded on my master page

          • #18 by Steve on March 17, 2013 - 4:51 pm

            No, your script is in tact as provided, I mean SharePoint’s javascript that is attached to the Web Part buttons.

            When clicking those, nothing happens, but also no javascript errors in the console.

      • #19 by Jeff on June 12, 2013 - 1:56 pm

        I’m getting the same issue that the Add Web Part is not launching the webpart bar under the ribbon as it should. There are no JS errors being thrown and I’ve confirmed that without the Reint() being called it works fine but with it it doesn’t show. I’m using Chrome and not IE, so the suggested fix to not call Reinit for non-IE isn’t applicable.

        I’ve narrowed down what is going on a bit. If Reinit is called, then calling ShowWebPartAdder() from the develper tools does not open the webpart area, but when Reinit is not called it does. So something in there is not working. I’ll keep digging and post if I find anything else.

        • #20 by Jeff on June 12, 2013 - 2:58 pm

          So the issue appears to be that when it calls ShowWebPartAddr() it does a post back to get all of the webparts to show in the new area it is creating. When the Reinit() method has been used as this post describes, the postback returns an HTML error page that says “This Page has been modified since you opened it. You must open the page again.”

          I haven’t found out why or how to get around that but may have found a solution, at least in my case.

          My body tag has onload=”javascript:_spBodyOnLoadWrapper();”, so I just removed that onload attribute completely and then the Reinit() method calls _spBodyOnLoadWrapper() and then the Add Web Part links work.

          I’ll be keeping an eye on it to make sure that it still resolves the scrollbar issue it was originally meant to, but it seems promising.

    • #21 by tuck on February 19, 2013 - 2:01 pm

      I was having the same issue but to get it fixed I just set the Timeout to setTimeout(Reinit,50) and it worked consistantly after that. The error I was getting was actually a post 500 error. Not sure if the address it was trying to post to is that important to anyone?

    • #22 by Milan Jaroš on April 8, 2013 - 5:00 am

      Same here… Unable to add webpart. Solution was to perform Reinit only for NON-IE browsers.

  9. #23 by Juan on April 15, 2013 - 3:05 pm

    Great solution, fixed alot of my problems.
    I used the github solution, but thx to the three of you.

  10. #24 by Maya on June 17, 2013 - 6:48 am

    this solution really saved a lot time.
    thank you very much.

  11. #25 by Jeremy on November 8, 2013 - 2:37 pm

    Hi Maarten, I’m new to Sharepoint and am trying to put together a shared document for work. I just realized the scrolling feature doesn’t work well and found your solution in doing a Google search. I really appreciate your post because this is exactly what I’m looking for. The trouble is, I’ve never implemented new java script before. Do you have a website or tutorial you recommend that I could check out so that I can learn to do this?
    Thanks! Jeremy

(will not be published)


%d bloggers like this: