828087 - Investigate mechanism for determining the "causing window" of a download for the launcher dialog

Status: NEW

(Firefox :: File Handling, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

The code in nsHelperAppDlg.js displays a URL of the download's origin. But to address issues like bug 741050, it also wants to be able to avoid showing a download (or cancel the download) if the origin of the page that caused the download to occur no longer matches the page being displayed.

I'm not sure offhand whether there's an easy way to define "origin that caused a download to occur", or how to best expose that to the front-end.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #0)
> The code in nsHelperAppDlg.js displays a URL of the download's origin. But
> to address issues like bug 741050, it also wants to be able to avoid showing
> a download (or cancel the download) if the origin of the page that caused
> the download to occur no longer matches the page being displayed.

Alternatively: focus the tab that caused the download to appear before showing the dialog.

Comment 2

[Marco Bonardo [:mak]]

is there a reason this dialog can't be tab-modal or just an infobar (provided it doesn't regress accessibility of the action, since downloading is quite an important action)? Could mean rewrite a new nsHelperAppDlg.js for browser (could also be a good time to make it use OS.File).
We could ask UX to evaluate a new download interaction.

Comment 3

[Florian Bender]

Does the new Download API provide the necessary information?

Comment 4

[:Paolo Amadini]

(In reply to Florian Bender from comment #3)
> Does the new Download API provide the necessary information?

The code in nsHelperAppDlg.js is executed before the Downloads API is notified of the download.

Once we understand what the new requirements are, we can design the most appropriate solution, and it might involve invoking the new Downloads API earlier in the process.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to Marco Bonardo [:mak] from comment #2)
> is there a reason this dialog can't be tab-modal or just an infobar
> (provided it doesn't regress accessibility of the action, since downloading
> is quite an important action)?

Hmm, is nsHelperAppDlg.js's this.mContext enough info to parent the dialog to the right tab?

Comment 6

[:Paolo Amadini]

This was a dependency of another bug previously in the Firefox Desktop Backlog, that was subsequently removed as it has been absorbed as part of other work (see bug 741050 comment 23).

I guess this bug needs to be removed from the backlog as well.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Re-cap of the actionable work here from discussion with Paolo:
- confirm that all of the relevant scenarios from bug 741050 go through nsIHelperAppLauncherDialog (paolo seems confident that this is the case)
- investigate whether the aWindowContext parameter to nsIHelperAppLauncherDialog::show() is a suitable solution to this problem (knowing which tab to associate the download dialog with) in all cases
- if it isn't, investigate other solutions (e.g. getting a window reference from the download channel and passing it through to nsIHelperAppLauncherDialog::show() somehow)

Comment 8

[Nicolas Barbulesco]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #0)

> The code in nsHelperAppDlg.js displays a URL of the download's origin. But
> to address issues like bug 741050, it also wants to be able to avoid showing
> a download (or cancel the download) if the origin of the page that caused
> the download to occur no longer matches the page being displayed.
> 
> I'm not sure offhand whether there's an easy way to define "origin that
> caused a download to occur", or how to best expose that to the front-end.

Yes, this rule is needed, this will be a great improvement of security ! 

But such rule should not be applied to the downloads triggered by user-entered address. Let's also exclude from this rule the downloads triggered by user-dropped address into empty or new tabs. 
When I create a new, empty tab and I paste an address to download a file, Firefox should not ignore this download.

By doing so, I think we would be on the safe side.

Comment 9

[Nicolas Barbulesco]

Let's suppose the following scenario : 

1. I have a tab displaying the page www.microsoft.com/internet-explorer 
2. I paste www.mozilla.org/firefox/firefox-mac.zip in the address bar

The download comes from a completely different source than the displayed page in the tab. 
Yet I expect Firefox to ask me to download the file, like Firefox does with all download attempts.

Comment 10

[Nicolas Barbulesco]

Sorry, a little omission. 
For step 2. I mean : right-click --> "Paste and go".