Closed Bug 420405 Opened 15 years ago Closed 15 years ago

Download triggered by <iframe src="...exe"> fails if containing page has refreshed

Categories

(Toolkit :: Downloads API, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: david.maza.AU, Assigned: asaf)

References

()

Details

(Keywords: regression, Whiteboard: [has patch][has reviews])

Attachments

(1 file)

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.
Keywords: regression
Summary: HTML, iFrames and META Redirects → Download triggered by <iframe src="...exe"> fails if containing page has refreshed
Anyone?
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: in-testsuite?
Flags: in-litmus?
Version: unspecified → Trunk
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?
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
Can we get a regression range here?
Thanks, Ria. Mano: any thoughts?
Flags: blocking-firefox3? → blocking-firefox3+
Assignee: nobody → mano
Whiteboard: [needs update Mano]
Trying to assign a priority to this.  How common is this in real life?
Mano?
Any updates?
Attached patch patchSplinter Review
Attachment #315512 - Flags: review?(mconnor)
Whiteboard: [needs update Mano] → [needs review mconnor]
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox 3
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+
Whiteboard: [needs review mconnor] → [has patch][has reviews]
um, test please?  This shouldn't be hard to do with the browser chrome test suite...
IMO, this shouldn't land without a test per toolkit testing requirements especially since this shouldn't be hard to test.
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.
The opener should be a chrome window, and the location of the content window withing that shouldn't affect it, right?
no, the opener is the content window which invoked the dialog.
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).
mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in 1.67
Status: ASSIGNED → RESOLVED
Closed: 15 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
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.