Loading Hotmail/Windows Live Calendar is broken

RESOLVED FIXED

Status

Tech Evangelism Graveyard
English US
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: xtc4uall, Assigned: hsivonen)

Tracking

({regression})

Details

(URL)

(Reporter)

Description

7 years ago
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

7 years ago
Henri, is this the known script ordering thing?

Comment 2

7 years ago
Reporter, does spoofing an IE UA fix things?

Comment 3

7 years ago
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

7 years ago
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

7 years ago
Given the regression range, yeah.  But since it's a different web property, marking dependent for now.
Depends on: 609236
Keywords: regressionwindow-wanted
We'll have a nicer evang story for this once bug 602838 lands.
Assignee: nobody → english-us
Component: General → English US
Depends on: 602838
Product: Core → Tech Evangelism
QA Contact: general → english-us
Version: Trunk → unspecified

Comment 7

7 years ago
Thanks for the report.
Getting the right folks on Hotmail Calendar involved.
Assignee: english-us → hsivonen
Status: NEW → ASSIGNED
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.
Depends on: 609236, 602838
No longer depends on: 609236, 602838
(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.
Blocks: 559610
Why is this an Evangelism bug instead of somewhere in platform? Is the scenario validly broken?

Comment 12

7 years ago
> 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!
Microsoft has a fix for this internally. I'll leave this bug open until the fix has been deployed.

Updated

7 years ago
Duplicate of this bug: 629262
(Reporter)

Comment 15

7 years ago
(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

7 years ago
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!
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.