Closed Bug 1203813 Opened 9 years ago Closed 8 years ago

iframe requires allow-popups to download

Categories

(Core :: DOM: Core & HTML, defect)

40 Branch
Unspecified
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: dgoldstein0, Unassigned)

References

Details

Attachments

(2 files)

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.
Could you attach a testcase, please.
Component: Untriaged → Security
Flags: needinfo?(dgoldstein0)
Product: Firefox → Core
Flags: needinfo?(dgoldstein0)
Attached 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.
OS: Unspecified → All
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)
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+
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a1ea2703d9e8
Make nsHelperAppDlg dialog be parented by top-level nsIDOMWindow. r=mrbkap
https://hg.mozilla.org/mozilla-central/rev/a1ea2703d9e8
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Depends on: 1279327
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.