Open Bug 1678965 Opened 5 months ago Updated 2 months ago

Downloads open up blank tab.

Categories

(Core :: DOM: Navigation, defect, P3)

Firefox 83
Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr78 --- unaffected
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- fix-optional

People

(Reporter: b66id0hw1, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Right click on a download link on a page, Firefox will open up a blank tab and then add that link to the Download queue but will not automatically close the tab.

Actual results:

Firefox does not automatically close blank tabs that it opens when downloading files. This was the normal behavior for years but it changed somewhere around v60? and then was fixed a few releases ago (late 70s) but it's back again. Chrome and etc. do this correctly so I'm not sure what has happened in the back end to make this change.

Expected results:

The download link should have opened the tab, added the link to the queue, and then Firefox should have automatically closed the 'empty' tab.

Component: Untriaged → Tabbed Browser

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)
Component: Tabbed Browser → DOM: Navigation
Flags: needinfo?(dao+bmo)
Product: Firefox → Core
See Also: → 1531289

(In reply to jeremiah from comment #0)

Right click on a download link on a page, Firefox will open up a blank tab

Pretty sure this is missing a step - are you using "save link as..." or "open link in new tab" or something else?

Can you provide an example link where this is broken for you? Can you test in a new Firefox profile ( https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles ) to clarify if the brokenness depends on any preferences you may have set or add-ons you may have installed?

Flags: needinfo?(b66id0hw1)

Nika fixed a similar bug in Fx83 (bug 1656753). Perhaps this bug is a regression from that code change?

See Also: → 1656753

Sorry, I meant middle click. I'm not sure how I missed that, I reviewed my post before submitting it -_-

What i meant was that if you open up a page with a list of links, it's easier to middle click on the ones you want and have them added to the queue instead of left clicking on them in series.

For ex., in Chrome, doing this (middle clicking on links) will open/close a new tab and add the links to your queue, most times Chrome won't even open up a new tab when you do this and just add the links to your queue. On the latest versions of FF, it will open new tabs for each link you click and then add them to your queue, without closing the empty tabs.

The way Chrome behaves was the way Firefox used to work on earlier versions but it changed around v60 or so, was fixed, and then was reverted again.

I am not sure if I have been clear enough so please let me know if there is any way for me to clarify this further.

Thank you for working on figuring out this bug!

Flags: needinfo?(b66id0hw1)

To try this, open up this page on both Chrome and in Firefox: https://windowsloop.com/direct-download-office-2016-office-2019-office-365-iso/

Now middle click on those links to the img/iso files and you will see how Chrome handles those links and how Firefox does. Chrome will open and close the page, and then add the link to your download queue, whereas Firefox will open a blank tab, will keep that tab open, and then will add the link to your queue.

That's just the only page that I could think of quickly but it illustrates my point well.

(In reply to Chris Peterson [:cpeterson] from comment #3)

Nika fixed a similar bug in Fx83 (bug 1656753). Perhaps this bug is a regression from that code change?

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0c42fffcbc6a6e8ffb1fab4210b5f226295b945&tochange=737f0e3e2f948d46cc39b44185e26df3021ab6ee

mozregression says yes, that's the regressor. Note that that bug was about the download not happening, because the tab closed too soon - now the tab doesn't close too soon, but ends up not closing at all. :-(

Nika, can you take a look?

I'm kind of astonished this didn't break tests - I'm 90% sure we do have some tests, because I remember it took some work to make defaulting to no-opener not break them (bug 1531289). The ISO links on the page in comment #5 have target=_blank as well as noopener/nofollow/noreferrer, in case that matters - but also, the STR involve middle-clicking (or cmd-click on macOS / ctrl-click on windows) those links.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(nika)
Keywords: regression
OS: Unspecified → All
Regressed by: 1656753
Hardware: Unspecified → Desktop
See Also: 1656753

Hmm, it looks like this was actually something semi-accidentally fixed by the changes in bug 1531289. The code to open a document with a middle-click doesn't actually go through the usual window opening machinery, instead it bounces out to chrome JS, which calls through tabbrowser to open the link in a specific location: (https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/browser/actors/ClickHandlerParent.jsm#117)

Because this goes through the parent process, not native window.open code, it never establishes either an opener or cross-group opener relationship between the original tab and the newly created one, so when the window closing logic looks for an opener window to parent the dialog to, it fails.

In the original approach we took in bug 1531289, the "fix" to the noopener window situation was to try to re-parent the dialog to the parent chrome window when the tab is going to be closed if no opener could be found. This unfortunately caused bug 1656753, as we'd immediately close that chrome window if a pop-up was created, and no dialog would be shown. To fix that I partially reverted back to the old opener based behaviour, and added a new CrossGroupOpener which would track the "opener" even in the case where a noopener flag prevents one from existing. This avoided the issue where we would target the dialog to a doomed parent window.

Unfortunately the context menu and click handler code doesn't currently communicate this relationship to platform code, so we do not attempt to close the newly created tab, as we don't know who to parent the potential download dialog to. If we want to also close downloads started with "right click -> open in new window" (or middle-click with opening in a pop-up supported), we'll probably need frontend to identify the cross-group opener window for us, but we can perhaps "fix" it in the new-tab case by asking nsIDocShellTreeOwner for the current tab count, and reparenting to the chrome window if it is over 1, sorta like we did before bug 1656753.

How tricky would it be to start tracking that context through frontend? It seems like it might be good to be explicit about these relationships so we don't show download dialogs in front of the wrong window if the tab is opened some other way (e.g. from extensions?).

Flags: needinfo?(nika) → needinfo?(gijskruitbosch+bugs)

(In reply to Nika Layzell [:nika] (ni? for response) from comment #8)

How tricky would it be to start tracking that context through frontend?

It's not super tricky to pass an extra arg (I guess canonical browsingcontext ref?) on the already huge params dict. What I'm less sure about is how we'd communicate the opener to the docshell/browsingcontext code, ie at what point do we pass a browsing context - do we need to set it as an attribute on the browser when creating that? Pass it to loadURI? Have we even got a mechanism for this directly in the parent, or do we need to create one? I'm also not sure how we'd avoid exposing an opener relationship to web content (which I'm fairly sure we don't want to do here).

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(nika)

We definitely wouldn't want to start exposing this relationship to web content, the idea here would be that we only preserve this information for internal bookkeeping. There's currently no mechanism for communicating the exact value to the internal code, so we'd need to add one, but it wouldn't be too difficult to add. The easiest option is probably to expose a setCrossGroupOpener() method on CanonicalBrowsingContext, and then have frontend call it after inserting the <browser> element, which should be fairly straightforward to do. We could also do an attribute or similar, but it seems unnecessary as we don't need to configure this value super early during context construction.

Flags: needinfo?(nika)
Flags: needinfo?(gijskruitbosch+bugs)

I've attached an example patch to expose the method which would be needed from JS, which hopefully can be built upon to fix this from frontend's side.

Nika's patch implements the platform changes. Rest of the fix is in frontend code.

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.