file download workflow breaks if triggered from an iframe which gets removed inbetween




7 years ago
3 years ago


(Reporter: wolfiR, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



7 years ago
This might be a invalid bug as I don't know if the following is supposed to work at all.

A JS webapp is providing a download functionality for documents and to achieve this it uses the following jQuery (should not matter) code:

var iframe = $("<iframe/>", { src: FILE_URL }).css({ 
  some, css 
}).one("load", function (e) {
  setTimeout(function () {
  }, 10);

So what Firefox does by default is to offer the dialog to "open" or "save" the file. Once the user choose "save" the dialog closes and no filechooser is coming up.

When I increase the timeout so I can actually open the save dialog before it times out it works fine.

As said I cannot tell if the webapp is allowed to do that but at least IE9 and Chrome can open a filedialog and download the file.
Removing the frame from the DOM will cancel the network request.

Do we actually fire a load event on the frame in that situation?  If so, with what callstack?  Seems like we should just not fire it until the download is done...

Comment 2

7 years ago
Apparently we fire a load event when the iframe is created. I added an alert() in the event handler and it comes up before the first download dialog. I'm not sure how to get a usable callstack for that certain event though. Any hints?
You have a debug build?

Just attach gdb, put a breakpoint in nsGlobalWindow::Alert, then run your testcase with an alert() in the load handler.  You'll hit the breakpoint, then just "bt" in gdb.

Comment 4

7 years ago
Created attachment 578515 [details]

Breakpoints gets hit two times before the alert popup comes up. Attaching both but they seem to be almost identical.

Comment 5

7 years ago
Created attachment 578516 [details]
Attachment #578515 - Attachment mime type: text/x-log → text/plain
Attachment #578516 - Attachment mime type: text/x-log → text/plain
Yeah, you're seeing forwarding from the inner window to the outer window.  Makes sense.

So we fire the onload when we retarget the load to the download manager, which is as soon as we receive the response headers.  So it's out of the loadgroup of the frame that goes away.  I wonder why the save fails, then...

I'll take a look tomorrow.

Comment 7

7 years ago
Actually an important information. The save works if Firefox is set to download always to a certain location. As soon as the filechooser is supposed to come up nothing happens anymore.

Comment 8

7 years ago
Another effect is that sometimes it also fails to display the first open/save dialog.
When I lower the timeout from the testcase even more there is a bigger chance that the first dialog also is not displayed.
To me it looks more like a window issue? Are the windows actually trying to use the iframe as a parent or context?


3 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: 9 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.