Closed Bug 581502 Opened 9 years ago Closed 9 years ago
Cannot download attachments from Hotmail on Fx4 B1
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.
Duplicate of 578416
Regression range? Why wasn't this nominated for blocking? Seems like a blocker if I ever saw one...
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:18.104.22.168) Gecko/20100722 Firefox/3.6.8 in about:config would be a useful test.
According to bug 582572 spoofing did not make a difference.
Blocking. Difficult to say if this would need beta coverage without understanding the problem better but flagging it as such in case.
blocking2.0: ? → betaN+
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.
Component: Download Manager → HTML: Parser
Product: Toolkit → Core
QA Contact: download.manager → parser
Summary: [Regression] Cannot download attachments from Hotmail on Fx4 B1 → Cannot download attachments from Hotmail on Fx4 B1
In addition to the Comment #8, If force html5.enable to true. Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca23d3b5a999&tochange=1c6ec6110a0f
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.
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.)
Whiteboard: [Input] → [Input] Pinpointing the precise cause of problem / minimized test case needed
(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.
Henri: what sort of QA help do you need here in order to figure this out?
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.
(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.
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?
shaver, see comment #16. Can you help bridge Henri with some MSFT folks?
(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.
We have contact with Microsoft now.
There's now a lead: The HTTP payload in 302 redirects getting parsed.
Comment 20 is pretty cryptic. Details?
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.
Yep. We ignore 302 bodies completely. We don't cache them, we don't parse them, nothing.
(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.
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.
This looks fixed both using a special test account and using my normal Windows Live account. Thanks!
Assignee: nobody → english-us
Status: NEW → RESOLVED
Closed: 9 years ago
Component: HTML: Parser → English US
Product: Core → Tech Evangelism
QA Contact: parser → english-us
Resolution: --- → FIXED
Whiteboard: [Input] Pinpointing the precise cause of problem / minimized test case needed
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.