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

NEW
Unassigned

Status

()

6 years ago
2 years ago

People

(Reporter: Gavin, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

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.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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.

Updated

5 years ago
Blocks: 950073
Whiteboard: p=0
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

5 years ago
Does the new Download API provide the necessary information?
Flags: needinfo?(paolo.mozmail)

Comment 4

5 years ago
(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.
Flags: needinfo?(paolo.mozmail)
(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

5 years ago
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.

Updated

4 years ago
No longer blocks: 950073
Flags: firefox-backlog?
Whiteboard: p=0

Updated

4 years ago
Summary: front-end needs a way to get the origin that caused a download to occur → Investigate parenting the dialog shown by nsHelperAppDlg.js to the tab that caused a download to occur

Updated

4 years ago
Summary: Investigate parenting the dialog shown by nsHelperAppDlg.js to the tab that caused a download to occur → Investigate mechanism for determining the "causing window" of a download

Updated

4 years ago
Summary: Investigate mechanism for determining the "causing window" of a download → Investigate mechanism for determining the "causing window" of a download for the launcher dialog
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)
Flags: firefox-backlog? → firefox-backlog+

Comment 8

4 years ago
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] 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

4 years ago
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

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

Updated

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