iframe requires allow-popups to download

RESOLVED FIXED in Firefox 52

Status

()

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: dgoldstein0, Unassigned)

Tracking

40 Branch
mozilla52
Unspecified
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 fixed)

Details

Attachments

(2 attachments)

Reporter

Description

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

Updated

4 years ago
Flags: needinfo?(dgoldstein0)
Reporter

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.
Reporter

Updated

4 years ago
OS: Unspecified → All
Reporter

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?
Status: UNCONFIRMED → NEW
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)

Updated

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:

http://searchfox.org/mozilla-central/rev/8cf1367dd89cc36ef8f025dfc6af6d5c086838a7/embedding/components/windowwatcher/nsWindowWatcher.cpp#879

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.

https://reviewboard.mozilla.org/r/88840/#review88238
Attachment #8805013 - Flags: review?(mrbkap) → review+

Comment 11

3 years ago
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a1ea2703d9e8
Make nsHelperAppDlg dialog be parented by top-level nsIDOMWindow. r=mrbkap

Comment 12

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/a1ea2703d9e8
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52

Updated

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.