Built from http://hg.mozilla.org/mozilla-central/rev/4ef3abd2012c. Open given URL and login. Site does not finish loading and gets stuck in the "Loading" Pre-Site. Worth to mention Error Console Output: Error: onJsLoaded is not defined Source file: http://bay04.calendar.live.com/calendar/calendar.aspx?wa=wsignin1.0 Line: 801 ---------- Error: Calendar is not defined Source file: http://gfx4.hotmail.com/cal/15.4.0108.1008/en-001/marketDateClass.js Line: 1 ---------- Error: Calendar is not defined Source file: http://gfx4.hotmail.com/cal/15.4.0108.1008/CalendarTaskView.js Line: 1 ---------- Error: $css is not defined Source file: http://js.wlxrs.com/HA2x3RVXuVMD4jIYf39lMA/shared.js Line: 1 Regressed within Beta 6 <-> 7. Happens on a recent TM Build (Built from http://hg.mozilla.org/tracemonkey/rev/c146eeb9fecc) too.
Henri, is this the known script ordering thing?
Reporter, does spoofing an IE UA fix things?
Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/268ef4ccb5ff Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre ID:20100917041014 Fails: http://hg.mozilla.org/mozilla-central/rev/bc15c280c430 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre ID:20100917044206 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=268ef4ccb5ff&tochange=bc15c280c430
And if set UA is not including "Firefox" then the proroblem does not hoppen. i.e. user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101109 Minefield/4.0b8pre"); Maybe this is duplication of Bug 609236
Given the regression range, yeah. But since it's a different web property, marking dependent for now.
We'll have a nicer evang story for this once bug 602838 lands.
Thanks for the report. Getting the right folks on Hotmail Calendar involved.
This is not about script-inserted external scripts maintaining order among themselves. (Or not only about that.) I made a build that defaulted to maintaining order among those, but the calendar load still got stuck. This is more likely about script-inserted external scripts not blocking subsequent parser-inserted scripts. Script-inserted external scripts don't block subsequent parser-inserted scripts in IE or WebKit, so I'm still guessing that browser sniffing is to blame here. To insert an external script during the page load so that subsequent parser-inserted scripts get blocked, document.write() is the cross-browser-compatible way. I wrote a blog post about this topic: http://hsivonen.iki.fi/script-execution/ It might take an hour or two for Windows and Mac nightlies where .async defaults to true to show up.
I experimented some more. The page depends both on script-inserted external scripts executing in the insertion order and on script-inserted external scripts blocking subsequent parser-inserted scripts. There are two cross-browser and HTML5-compatible ways to fix this: 1) Using document.write("\u003Cscript src='foo.js'>\u003C/script>"); to insert the scripts that need to block the parser. The disadvantage is that the page needs to load multiple scripts using this mechanism, but the scripts won't load in parallel until bug 543062 is fixed. 2) Simply loading all the necessary scripts by putting <script src="foo.js"></script> tags in the page source. This is the most performant alternative, since Firefox will start fetching the scripts earlier and will fetch them in parallel.
(In reply to comment #9) > The disadvantage is that the page > needs to load multiple scripts using this mechanism, but the scripts won't load > in parallel until bug 543062 is fixed. Bug 543062 is now fixed, so that's no longer a problem.
Why is this an Evangelism bug instead of somewhere in platform? Is the scenario validly broken?
Microsoft has a fix for this internally. I'll leave this bug open until the fix has been deployed.
(In reply to comment #13) > Microsoft has a fix for this internally. I'll leave this bug open until the fix > has been deployed. This seems to fixed by at least Today (Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre ID:20110202030356 + Redirect to http://bay04.calendar.live.com after Login). Somebody else can confirm and resolve?
Confirmed.I can not reproduce. Redirect to http://bay04.calendar.live.com/calendar/calendar.aspx
Yeah, it looks like the fix has been deployed now. Marking FIXED. Thank you for fixing!