iframe requires allow-popups to download

RESOLVED FIXED in Firefox 52



4 years ago
2 years ago


(Reporter: dgoldstein0, Unassigned)


40 Branch
Dependency tree / graph

Firefox Tracking Flags

(firefox52 fixed)



(2 attachments)



4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce:

Background: A common pattern to force a download of a file on the web is to make an http request for that file and return the file in the response with a header "Content-Disposition: attachment; filename=blah".  This works ok, but has a bunch of drawbacks when done as page navigation (e.g. downloads cancelling when other navigation happens before the response headers are received).  So as a workaround, it's common to create an iframe with src=<download url> and let the iframe trigger the download.

This normally works.  However, if the iframe has a sandbox attribute without allow-popups, the download does not work consistently in all browsers.

Actual results:

In Google Chrome, adding such an iframe to the page results in a download.  In Firefox, the download is silently blocked (when Firefox has default settings).

Expected results:

Loading a "content-disposition: attachment" response in an iframe should trigger a download, ideally regardless of the sandbox attribute.

Alternatively, if this nonstandard behavior is going to be kept, it should be documented with the iframe sandbox attribute on MDN.

Comment 1

4 years ago
Could you attach a testcase, please.
Component: Untriaged → Security
Flags: needinfo?(dgoldstein0)
Product: Firefox → Core


4 years ago
Flags: needinfo?(dgoldstein0)

Comment 2

4 years ago
Posted file testcase.html
this html file should, on load, kick off a download of a file in my Dropbox (a png of mario).  It does so in Chrome, but not in Firefox.


4 years ago
OS: Unspecified → All

Comment 3

4 years ago
set OS to All - I've repro'd on Windows 7 and this was originally discovered on OS X (where I've also repro'd).
I see the problem in Firefox 40, but things work correctly in a nightly.... but only in e10s mode.

The problem is that the implementation of the "@mozilla.org/helperapplauncherdialog;1" uses the window watcher to open the dialog (with the "chrome,dialog=yes" window features).  And the window watcher has unconditional sandbox checks, added in bug 766282, that block the window opening.

We should probably skip those checks based on the window features or something, but I'm not sure what the right set of checks to skip it actually is.  Olli, any ideas?
Ever confirmed: true
Flags: needinfo?(bugs)
I don't know what component this belongs in, but it's not Security.
Component: Security → Untriaged
Mike, sorry to dump more stuff on you, but thoughts on comment 4?
Flags: needinfo?(mconley)


3 years ago
Component: Untriaged → DOM: Core & HTML
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #4)

> The problem is that the implementation of the
> "@mozilla.org/helperapplauncherdialog;1" uses the window watcher to open the
> dialog (with the "chrome,dialog=yes" window features).  And the window
> watcher has unconditional sandbox checks, added in bug 766282, that block
> the window opening.

It possibly doesn't matter, but in case it helps track down when the bug was introduced, the check was originally added in bug 341604, which would always block with the sandbox attribute.
Bug 766282, changed this check to allow it with the allow-popups keyword.
So nsHelperAppDlg for toolkit stores the "parent context" of whatever kicked off the network request. In the non-e10s case, this happens to be the nsIDOMWindow for your sandboxed <iframe>. nsHelperAppDlg passes that nsIDOMWindow in as the parent to nsIWindowWatcher, and eventually we hit this:


Here, we've looked at the sandbox flags for the parent window to see if they allow popups. In this case, for the iframe, the answer is "no", and so we bail.

In the non-e10s case, we don't have access to the nsIDOMWindow of the requesting content - I believe we have the parent be the top-level XUL window instead. We can probably do the same for the non-e10s case.

Patch coming up.
Flags: needinfo?(mconley)
Comment on attachment 8805013 [details]
Bug 1203813 - Make nsHelperAppDlg dialog be parented by top-level nsIDOMWindow.

Attachment #8805013 - Flags: review?(mrbkap) → review+

Comment 11

3 years ago
Pushed by mconley@mozilla.com:
Make nsHelperAppDlg dialog be parented by top-level nsIDOMWindow. r=mrbkap

Comment 12

3 years ago
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52


3 years ago
Depends on: 1279327
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.