Closed
Bug 581502
Opened 13 years ago
Closed 12 years ago
Cannot download attachments from Hotmail on Fx4 B1
Categories
(Tech Evangelism Graveyard :: English US, defect, P2)
Tech Evangelism Graveyard
English US
Tracking
(blocking2.0 betaN+)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: aakashd, Unassigned)
References
Details
(Keywords: regression)
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•13 years ago
|
||
Duplicate of 578416
![]() |
||
Comment 4•13 years ago
|
||
Regression range? Why wasn't this nominated for blocking? Seems like a blocker if I ever saw one...
blocking2.0: --- → ?
Keywords: regression,
regressionwindow-wanted
Comment 5•13 years ago
|
||
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•13 years ago
|
||
According to bug 582572 spoofing did not make a difference.
Comment 7•13 years ago
|
||
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+
![]() |
||
Comment 8•13 years ago
|
||
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.
Updated•13 years ago
|
Keywords: regressionwindow-wanted
![]() |
||
Updated•13 years ago
|
Component: Download Manager → HTML: Parser
Product: Toolkit → Core
QA Contact: download.manager → parser
Updated•13 years ago
|
Summary: [Regression] Cannot download attachments from Hotmail on Fx4 B1 → Cannot download attachments from Hotmail on Fx4 B1
![]() |
||
Comment 9•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.)
Keywords: qawanted
Whiteboard: [Input] → [Input] Pinpointing the precise cause of problem / minimized test case needed
Comment 12•13 years ago
|
||
(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•13 years ago
|
||
Henri: what sort of QA help do you need here in order to figure this out?
![]() |
||
Comment 14•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
shaver, see comment #16. Can you help bridge Henri with some MSFT folks?
Comment 18•13 years ago
|
||
(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•13 years ago
|
||
We have contact with Microsoft now.
Comment 20•13 years ago
|
||
There's now a lead: The HTTP payload in 302 redirects getting parsed.
Updated•13 years ago
|
Priority: -- → P2
![]() |
||
Comment 21•13 years ago
|
||
Comment 20 is pretty cryptic. Details?
Comment 22•13 years ago
|
||
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•13 years ago
|
||
Yep. We ignore 302 bodies completely. We don't cache them, we don't parse them, nothing.
Comment 24•13 years ago
|
||
(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•13 years ago
|
||
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•12 years ago
|
||
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: 12 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
Updated•8 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•