Closed
Bug 420405
Opened 16 years ago
Closed 16 years ago
Download triggered by <iframe src="...exe"> fails if containing page has refreshed
Categories
(Toolkit :: Downloads API, defect, P1)
Toolkit
Downloads API
Tracking
()
VERIFIED
FIXED
mozilla1.9
People
(Reporter: david.maza.AU, Assigned: asaf)
References
()
Details
(Keywords: regression, Whiteboard: [has patch][has reviews])
Attachments
(1 file)
5.94 KB,
patch
|
mconnor
:
review+
mconnor
:
approval1.9+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 Visit a page with a META Redirect on 0 seconds, with an iFrame pointing to an exe file. Reproducible: Always Steps to Reproduce: 1. Create a HTML page with an iframe to an .exe file and a META redirect in 0 seconds 2. Visit it in Firefox 3.0 3. You'll be presented with a Download window, with the option to Save Now or to Cancel. IF you click Save Now after the redirection then the download will not start. IF you click Save Now before the redirection then the download will start. This never happened with Firefox 2.0 Actual Results: You'll be presented with a Download window, with the option to Save Now or to Cancel. IF you click Save Now after the redirection then the download will not start. IF you click Save Now before the redirection then the download will start. This never happened with Firefox 2.0 Expected Results: Download starts, but you need good timing.
Updated•16 years ago
|
Keywords: regression
Summary: HTML, iFrames and META Redirects → Download triggered by <iframe src="...exe"> fails if containing page has refreshed
Reporter | ||
Comment 1•16 years ago
|
||
Anyone?
Reporter | ||
Updated•16 years ago
|
Severity: normal → major
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•16 years ago
|
Flags: in-testsuite?
Flags: in-litmus?
Version: unspecified → Trunk
Reporter | ||
Comment 2•16 years ago
|
||
http://s2.photobucket.com/albums/y17/quick_6066/?action=view¤t=Movie-4.flv
Comment 3•16 years ago
|
||
I can reproduce with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre; I think we might have an existing bug on this, though I'll have to check.
Flags: blocking-firefox3?
Comment 4•16 years ago
|
||
in-litmus+ https://litmus.mozilla.org/show_test.cgi?id=5215 Thanks for the excellent bug and testcase, David!
Flags: in-litmus? → in-litmus+
OS: Windows Vista → All
Hardware: PC → All
Comment 5•16 years ago
|
||
Can we get a regression range here?
Comment 6•16 years ago
|
||
Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-11-05+08%3A00&maxdate=2006-11-05+14%3A00 Bug 353560 seems the most likely cause.
Blocks: 353560
Comment 7•16 years ago
|
||
Thanks, Ria. Mano: any thoughts?
Updated•16 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Updated•16 years ago
|
Assignee: nobody → mano
Whiteboard: [needs update Mano]
Comment 8•16 years ago
|
||
Trying to assign a priority to this. How common is this in real life?
Comment 9•16 years ago
|
||
Mano?
Reporter | ||
Comment 10•16 years ago
|
||
Any updates?
Assignee | ||
Comment 11•16 years ago
|
||
Attachment #315512 -
Flags: review?(mconnor)
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs update Mano] → [needs review mconnor]
Assignee | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox 3
Comment 12•16 years ago
|
||
Comment on attachment 315512 [details] [diff] [review] patch r+a=mconnor Please do explain why we can't use the timeout here, but this is the right impl in any case.
Attachment #315512 -
Flags: review?(mconnor)
Attachment #315512 -
Flags: review+
Attachment #315512 -
Flags: approval1.9+
Updated•16 years ago
|
Whiteboard: [needs review mconnor] → [has patch][has reviews]
Comment 13•16 years ago
|
||
um, test please? This shouldn't be hard to do with the browser chrome test suite...
Comment 14•16 years ago
|
||
IMO, this shouldn't land without a test per toolkit testing requirements especially since this shouldn't be hard to test.
Assignee | ||
Comment 15•16 years ago
|
||
I don't know how (In reply to comment #12) > (From update of attachment 315512 [details] [diff] [review]) > r+a=mconnor > > Please do explain why we can't use the timeout here, but this is the right impl > in any case. > Because the opener is closed/refreshed.
Comment 16•16 years ago
|
||
The opener should be a chrome window, and the location of the content window withing that shouldn't affect it, right?
Assignee | ||
Comment 17•16 years ago
|
||
no, the opener is the content window which invoked the dialog.
Might this fix bug 429224 also?
Comment 19•16 years ago
|
||
ben, its possible, yeah, but dunno for sure. I think we can land this without a test for now, I don't current know of a good way to trigger the dialog response via the testsuite, and that's the interaction we need to test, so I'm going to exempt this for now (and note that in-testsuite? is set already).
Assignee | ||
Comment 20•16 years ago
|
||
mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in 1.67
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified FIXED using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041904 Minefield/3.0pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008041904 Minefield/3.0pre -and- Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041907 Minefield/3.0pre
Status: RESOLVED → VERIFIED
Updated•15 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•