610917 - Loading Hotmail/Windows Live Calendar is broken

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Henri, is this the known script ordering thing?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Reporter, does spoofing an IE UA fix things?

Comment 3

[Alice0775 White]

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

Comment 4

[Alice0775 White]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

Given the regression range, yeah.  But since it's a different web property, marking dependent for now.

Comment 6

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

We'll have a nicer evang story for this once bug 602838 lands.

Comment 7

[Raul D @ Yahoo!]

Thanks for the report.
Getting the right folks on Hotmail Calendar involved.

Comment 8

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

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.

Comment 9

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

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.

Comment 10

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

(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.

Comment 11

[Dietrich Ayala (:dietrich)]

Why is this an Evangelism bug instead of somewhere in platform? Is the scenario validly broken?

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Why is this an Evangelism bug instead of somewhere in platform?

Because they're sniffing browsers and sending us broken code.

> Is the scenario validly broken?

Yes.  Do read comment 4 and comment 9, please!

Comment 13

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Microsoft has a fix for this internally. I'll leave this bug open until the fix has been deployed.

Comment 15

[(mostly gone) XtC4UaLL [:xtc4uall]]

(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?

Comment 16

[Alice0775 White]

Confirmed.I can not reproduce.
Redirect to http://bay04.calendar.live.com/calendar/calendar.aspx

Comment 17

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Yeah, it looks like the fix has been deployed now.

Marking FIXED. Thank you for fixing!