581502 - Cannot download attachments from Hotmail on Fx4 B1

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect, P2)

Description

[Aakash Desai [:aakashd]]

Build Id:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1

Note: This may be due to UA sniffing, but I'm not entirely sure. Also, we're seeing this with a number of users from Input vis Win XP and OSX 

http://input.mozilla.com/en-US/search/?q=hotmail+attachment&product=firefox

Steps to Reproduce:
1. Log into hotmail
2. Open an e-mail with an attachment
3 [review]. Try to download and open the attachment (it should be blocked)
4. Try it again (now unblocked).
5. Try it a few more times.

Actual Results:
The content continues to go from blocked to unblocked, but the attachment is never installed. This works fine on Chrome, Safari and Fx 3.6.8

Expected Results:
I should be able to download the attachment after unblocking the content.

Comment 1

[Danny Yang]

Duplicate of 578416

Comment 4

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Regression range?  Why wasn't this nominated for blocking?  Seems like a blocker if I ever saw one...

Comment 5

[Kevin Brosnan]

It would be good to know if spoofing a Firefox 3.6 user agent fixes this. Setting general.useragent.override to Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 in about:config would be a useful test.

Comment 6

[Josh Matthews [:jdm]]

According to bug 582572 spoofing did not make a difference.

Comment 7

[Dave Townsend [:mossop] (he/him)]

Blocking. Difficult to say if this would need beta coverage without understanding the problem better but flagging it as such in case.

Comment 8

[Alice0775 White]

Possibly regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/5b4d16af6e6b
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100502 Minefield/3.7a5pre ID:20100502160919
Fails:
http://hg.mozilla.org/mozilla-central/rev/3a7920df7580
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100503 Minefield/3.7a5pre ID:20100503105056
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5b4d16af6e6b&tochange=3a7920df7580

When I set html5.enable to false, then download performed successfully.

Comment 9

[Alice0775 White]

In addition to the Comment #8,
If force html5.enable to true.
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca23d3b5a999&tochange=1c6ec6110a0f

Comment 10

[Henri Sivonen (:hsivonen)]

The part of the DOM that represents the attachment download UI is identical with both parsers. There isn't an explicit onclick attribute for downloading in either case. Higher up in the tree there is an explicit onclick that toggles the view.

I'm guessing something fails to attach a download trigger event handler below the view toggle in the tree.

Comment 11

[Henri Sivonen (:hsivonen)]

I examined the DOM created by the HTML5 parser. I didn't see any signs of trouble caused by HTML5 tokenization.

I did notice some async scripts and some defer scripts. Those are obviously suspicious. However, the error console indicates that no document.writes got ignored.

Marking qawanted, since I could really use some help with figuring out what's really going on here. (I wouldn't be too surprised if this turned out to be evang material.)

Comment 12

[Henri Sivonen (:hsivonen)]

(In reply to comment #9)
> In addition to the Comment #8,
> If force html5.enable to true.
> Pushlog:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca23d3b5a999&tochange=1c6ec6110a0f

This suggests that async scripts are not to blame, because (well, IIRC, at least) they weren't supported back in those days.

Also, since it goes all the way back to the initial landing of the HTML5 parser, this isn't an artifact of off-the-main-thread parsing, either.

Given that I didn't find any obvious evidence of tokenizer-related issues, my best guess currently is that some differing tree builder behavior confuses some script.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Henri: what sort of QA help do you need here in order to figure this out?

Comment 14

[Alice0775 White]

FYI.
I do not know what happens, However,The download succeeds when I delete a node (iframe id="historyFrame") from DOM before selecting an E-mail.

Comment 15

[Henri Sivonen (:hsivonen)]

(In reply to comment #13)
> Henri: what sort of QA help do you need here in order to figure this out?

I need help pinpointing the reason of failure on the level of detail similar to "old parser treats token X in way Y_1 when the current element is Z but the new parser treats it as Y_2" or "old parser does foo synchronously when bar happens" or somesuch.

(In reply to comment #14)
> FYI.
> I do not know what happens, However,The download succeeds when I delete a node
> (iframe id="historyFrame") from DOM before selecting an E-mail.

Thanks!

I don't see anything suspicious in the source of the iframe tag or immediately before or after it. I also don't see anything suspicious in the document that gets initially loaded into the iframe.

By superficial inspection, the identifiers inside the script that's in the document that gets loaded in the iframe suggest that the purpose of the iframe is to hack in Back button support in an Ajaxy app without requiring the HTML5 history API.

I can't think of how this could be parser-relevant except if the script is accidentally sensitive to the relative order of event queue tasks. The off-the-main-thread parsing feature makes the event loop spin differently before the load event fires compared to the old parser.

Comment 16

[Henri Sivonen (:hsivonen)]

Do we know anyone at Microsoft who could be contacted in order to get help with pinpointing the cause of this problem from someone who knows the Hotmail code and has access to the unobfuscated JS?

Comment 17

[Reed Loden [:reed] (use needinfo?)]

shaver, see comment #16. Can you help bridge Henri with some MSFT folks?

Comment 18

[Henri Sivonen (:hsivonen)]

(In reply to comment #10)
> I'm guessing something fails to attach a download trigger event handler below
> the view toggle in the tree.

It seems that the <a> that says "Download" gets the same onclick event handler with or without the HTML5 parser after all, so I guess getting the event handler in place isn't the problem and the problem is whatever that event handler does. Unfortunately, when the event handler runs, quite a bit of obfuscated code gets run.

Comment 19

[Henri Sivonen (:hsivonen)]

We have contact with Microsoft now.

Comment 20

[Henri Sivonen (:hsivonen)]

There's now a lead: The HTTP payload in 302 redirects getting parsed.

Comment 21

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Comment 20 is pretty cryptic.  Details?

Comment 22

[Henri Sivonen (:hsivonen)]

The response from Microsoft is that what's failing is a 302 redirect whose HTTP response body contains the concatenation of two HTML documents that second of which contains a script.

It shouldn't matter if a 302 redirect response comes with bogus HTML--the body of the response shouldn't matter at all, since the redirect should happen based on the HTTP status code and HTTP headers.

Comment 23

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Yep.  We ignore 302 bodies completely.  We don't cache them, we don't parse them, nothing.

Comment 24

[Henri Sivonen (:hsivonen)]

(In reply to comment #23)
> Yep.  We ignore 302 bodies completely.  We don't cache them, we don't parse
> them, nothing.

Yeah, our redirect handling seems to work OK. (Test case: http://hsivonen.iki.fi/test/hotmail-redirect.php ) The contact at Microsoft is reinvestigating.

Comment 25

[Raul D @ Yahoo!]

Henri,

There was an unintended history navigation event being fired by our code that then caused a race condition, frequently cancelling the request for the download. We've taken a fix on the Hotmail side and verified it. We will be releasing this to our livesite soon.

Thanks for the report.

(In reply to comment #24)
> (In reply to comment #23)
> > Yep.  We ignore 302 bodies completely.  We don't cache them, we don't parse
> > them, nothing.
> Yeah, our redirect handling seems to work OK. (Test case:
> http://hsivonen.iki.fi/test/hotmail-redirect.php ) The contact at Microsoft is
> reinvestigating.

Comment 26

[Henri Sivonen (:hsivonen)]

This looks fixed both using a special test account and using my normal Windows Live account.

Thanks!