SP.SOD.executeOrDelayUntilScriptLoaded not working reliably in Chrome

Question

SharePoint 2010 ExecuteOrDelayUntilScriptLoaded is not working reliably in Chrome.  It does work reliably in IE, however..

 

Even a simple example like:

 

 

SP.SOD.executeOrDelayUntilScriptLoaded(blah, "SP.js");
function blah(){
 alert('!');
}

 

does not work reliably when the page is loaded.  It will *sometimes* work with a complete page refresh.  But this is unacceptable when using SP javascript API for web-facing applications..

 

Answer 1

Hi markth,

According to the description of  Plan brower support(SharePoint Server 2010) in SDK, the Chrome seems not included in the tested brower, so sometimes there will be some issues with Chrome. I recommend you use Internet Explorer as your browser.

Thanks,
Simon

Answer 2

HI Markth - I am seeing something similar. Our SP2010 branding was working fine in Chrome 12. Soon as Chrome 13 came out started seeing all kinds of wierdness. Ribbon would not work, scrollbars would not render etc. I was also thinking it was one of the SP.SOD functions but was having a hard time debugging it. 

Using the native templates and branding, SP2010 seems ok with Chrome 13 - So I am not sure what is going wrong. Would love to find out.

 

Marc

 

Answer 3

 

I'm seeing a similar issue. I'm not certain that executeOrDelayUntilScriptLoaded is the culprit though. It may be working as expected. 

The reason I say this is that when I open up Chrome developer tools, click the scripts tab and then click the dropdown that shows the downloaded script files, none of the sp.-.js files appear in the list. Since the issue is intermittent, I am able to confirm that the sp.-.js files are appearing when the problem does not occur. This suggests to me that executeOrDelayUntilScriptLoaded could be working perfectly, but that the delayed functions don't run because the required sp.js script never loads. 

Assuming this is what is happening, the question becomes why are the sp scripts not loading in Chrome 13. 

Note that I did find a version of Chrome 12 to install and confirmed that the issue does not arise in that older version.

 

If anyone has found a solution to this issue, please post it. This is a significant problem for a soon-to-launch public-facing site.

 

Answer 4

Thanks for posting guys - reassuring that I am not the only one running into this issue.  

@Shimin Huang - Recommending that we be lazy and tell our customers to use IE is an unacceptable solution for a public-facing site.  I would much rather be professional and try to find out the cause of the issue and determine if a workaround is possible.

Answer 5

I still have not found a remedy for this. In all of my googling, this is the only thread that appears to be discussing this problem. I suppose it is because the issue never existed prior to the release of chrome 13 on 8/4/2011. 

Here are a few more things I observed:

(1) Although the problem appears "intermittent" in that whether or not the error is produced on page refresh appears to be somewhat random, I can reliably get the error to occur by opening a brand new Chrome tab and pasting in the page address. Neither F5 nor CTRL F5 provide this reliability. 

(2) If I take an oob master page (v4.master), I can get it to produce this error in Chrome by linking to both jquery and spservices files. Both of these files are required for much of the site functionality. I have tried linking both using traditional methods and the preferred Sharepoint method, asp:ScriptReference, but the problem occurs in both cases. I have also tried placing the links in different locations in the master page but this does't seem to change anything.

(3) Features that stop working for me when the bug occurs include out of the box global nav dropdowns as well as custom scripts that use the client object model (ecmascript). Interestingly, custom scripts that use spservices do not appear to exhibit any problems. Spservices must access the client object resources in a different way.

Know anything more about this? Please post any additional observations. We need to identify a solution and get clarity on the root cause.

By the way, I agree with markth. Simply dismissing the issue by saying SP won't work with Chrome is tantamount to saying that SharePoint is not an acceptable option for outward-facing sites. We have already spent a lot of resources based on the assumption that SP was an acceptable public-facing solution so Shimin Huang's suggestion is not an option.

Answer 6

I think I found my answer - not sure if it will help you but here ya go:

1. Our template master page had an additional SharePoint:ScriptLink reference to sp.js - needed to remove this

2. Additionally, our master page has an iframe that displays another sharepoint webpart page. If we specified the src for the iframe inline the page would fail to render (no scrollbars and the ribbon would fail) - and as traindog said above, the Developer Console showed some js files not loading (like sp.ribbon.js). So we changed this to have the src=blank page and then set the correct src On Document Ready - so after the rest of the main page loads.

Both of those changes fixed our Chrome 13+ issues.

traindog - thanks for pointing me in the right direction.

Marc

 

Answer 7

Marc, I am glad that you were able to resolve your issues and that some of my observations were helpful. And thanks for posting your solution. However, our site has neither an explicit reference to sp.js nor an iframe in the master page so the changes you described will not apply. And we are still experiencing the issues described in item (3) of my Tuesday, August 23, 2011 9:32 PM post. I am still hoping that Microsoft or Google will provide a solution to this so that we don't need to resort to hacks. If anyone else has further information on this issue, please do post.

Answer 8

I discovered something that seems to have fixed the issue for me.

My master page has the following

 

<body scroll="no" onload="if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();" class="v4master">

 

I found that if I used the in-browser script console and called _spBodyOnLoadWrapper(), the scrollbars would be added properly to my window and the SOD functions would work properly again.

It seems to me that the body onload is not being called reliably in Chrome. I'm not sure what could be causing this, as the onload event seems to be fired reliably on a very simple html page when trying to reproduce the issue.

 

Since I am using jQuery anyway, I pulled the code from the body onload and instead used a jQuery document ready method to call this: 

 

<script type="text/javascript">
		$(document).ready(function(){
			if (typeof(_spBodyOnLoadWrapper) != 'undefined') 
			{
				_spBodyOnLoadWrapper();
			}
		});
</script>

 

and now my body tag looks like this:

 

<body scroll="no" class="v4master">

 

Anyway - this seems to have solved my issue. Please try and let me know if this works for you as well.

 

Answer 9

Shimin,

Google Chrome is becoming a very popular browser, and has to be tested against when building Internet-facing sites. If you look at the stats of the W3schools site commonly used by web developers, you will find that IE is sliding down and Chrome taking the lead (http://www.w3schools.com/browsers/browsers_stats.asp). Have a look at the global browser usage trends at http://en.wikipedia.org/wiki/Usage_share_of_web_browsers. According to the chart, it is easy to estimate that Google Chrome can take the lead in the browser's usage in as little as 2 years. Our clients estimate their Internet-facing site life-span of 5 years or more.

Rock,

Ignorance is not an answer. If a SharePoint solution was working in an earlier version of the browser, the problem may be caused by the Chrome itself, or by SharePoint. Knowing how bloated SharePoint is it is hard to rule out a problem with the SharePoint. Is the problem going to re-occur with a FireFox or a Safari update in near future? Was the Chrome update installed on the developer's machine around the time a SharePoint update was installed on the server?

Based on your answer, should I stop recommeding SharePoint to the potential clients that are planning on using SharePoint publishing features for an internet-facing site?

 

Mark,

Thank you for finding a work-around. Well done!

Answer 10

Markth,

How about that! Your remedy seems to have solved our issue as well. Chrome 13 does appear to have an intermittent problem with the body onload. I wonder if this is manifesting as a problem in non-SharePoint scenarios.

Many thanks for sharing this solution.

Answer 11

I just had the same issue. This trick works.

Thanx, VaBr

---