Closed Bug 1188732 Opened 10 years ago Closed 4 years ago

Downloads in Private Window are canceled if about:downloads is open and you close the last tab if new tab is set to blank page or an extension page

Categories

(Firefox :: Private Browsing, defect)

Product:
Firefox
Component:
Private Browsing
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox42 + verified disabled
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional

People

(Reporter: theo, Unassigned)

References

Details

(Keywords: regression)

STR: 1. Open a new Private Window 2. Download a file. From http://www.ubuntu.com/download/desktop/thank-you/?version=14.04.2&architecture=amd64 for instance or a new Firefox build. 3. Click on Download manager icon in toolbar 4. Click on "Display all downloads" 5. about:downloads opens in a new tab (and you can see your download) 6. Close the other tab (The one from which you started the download). Actual results: Your download is canceled and disappears from the download manager. Expected results: Your download is still ongoing. Tested on Ubuntu 15.04. Can reproduce the issue on latest Nightly (42). Can't reproduce on Dev Edition from 2015-07-28 [Tracking Requested - why for this release]: Quite a bad regression, download is lost, user is not warned.
Thank you, it would be nice to figure a regression-window for this using mozregression
Keywords: regressionwindow-wanted
Last good build: -> When a download starts from a Private Window, it's handled by the download manager in the *regular* window build_date: 2014-11-10 build_path: /tmp/tmp1Vb_uY/2014-11-10--mozilla-central--firefox-36.0a1.en-US.linux-x86_64.tar.bz2 build_txt_url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-10-03-02-04-mozilla-central/firefox-36.0a1.en-US.linux-x86_64.txt build_type: nightly build_url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-10-03-02-04-mozilla-central/firefox-36.0a1.en-US.linux-x86_64.tar.bz2 changeset: d380166816dd pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d380166816dd&tochange=cbe6afcae26c repo: mozilla-central repository: https://hg.mozilla.org/mozilla-central First bad build: -> When a download starts from a Private Window, it's handled by the download manager in the *private* window build_date: 2014-11-11 build_path: /tmp/tmp1Vb_uY/2014-11-11--mozilla-central--firefox-36.0a1.en-US.linux-x86_64.tar.bz2 build_txt_url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-11-03-02-03-mozilla-central/firefox-36.0a1.en-US.linux-x86_64.txt build_type: nightly build_url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/11/2014-11-11-03-02-03-mozilla-central/firefox-36.0a1.en-US.linux-x86_64.tar.bz2 changeset: cbe6afcae26c pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eb0d3b3c0b22&tochange=7f0d92595432 repo: mozilla-central repository: https://hg.mozilla.org/mozilla-central
Keywords: regressionwindow-wanted
Actually in 2014-11-10 build, if you close the private tab from which you started the download, it stops the download in the regular window as well. Looking for another regression-window.
Tracking in 42 because regression and very annoying behavior for the user. Adding status flag affected to 42, see STR.
status-firefox42: --- → affected
tracking-firefox42: ? → +
Looks like we are going to release 42 with this bug.
status-firefox42: affected → verified disabled
The bug seems to take place ONLY if new-tab page is overridden by an extension (with the "chrome_url_overrides" -> "newtab" manifest property). I encountered the issue with my own local (unpublished) extension, but the bug also reproduces with e.g. New Tab Tools. Tested with the latest Nightly (61.0a1 20180328220110) and Developer Edition (60.0b7 20180326164103) and New Tab Tools 86.5. The bug is INCREDIBLY annoying.
It also happens with the new tab page set to blank page (browser.newtabpage.enabled = false).
Blocks: 1417155
Summary: Downloads in Private Window are canceled if about:downloads is open and you close the last tab → Downloads in Private Window are canceled if about:downloads is open and you close the last tab if new tab is set to blank page or an extension page
Easy to reproduce: 1. In settings make sure "New tabs" is set to "Blank Page" 2. Start a download that takes a while to finish 3. Click on the downloads icon and then on "Display all downloads" 4. Close all tabs except the one that shows the download progress bar => Downloads will be cancelled and lost Note: Even browser.tabs.closeWindowWithLastTab=false does NOT prevent this!
status-firefox63: --- → affected
Too late to fix in 64. Marking this issue as fix-optional for 65; if you land a patch in nightly and think it's low-risk for beta, please request uplift.
status-firefox64: fix-optional → wontfix
status-firefox65: affected → fix-optional

Did not encounter the issue for a while, but now with Firefox 80 (Developer Edition 80.0b5), the issue seems to return. So there is probably a regression compared with Firefox 79 and older where the issue was apparently already fixed.

You start a download in a private window, you close the last tab, an empty tab is automatically opened instead, downloads are cancelled and disappearing as if there were no downloads running at all. No even a need for about:downloads to be opened for the issue to appear.

This one is very easily reproducible and started happening with Firefox 80. Even if about:downloads tab is open, if you close all the other tabs in Private Mode when downloading files that were triggered on these Private Tabs, then the downloads are cancelled without a warning.

I can reproduce this. It appears the problem is that a last-pb-context-exited notification is sent by docshell or ContentChild, because the about:downloads page is loaded with system principal and doesn't have private browsing state, so it is not counted.

Johann (feel free to forward), is there a straightforward way of fixing this? Feels like we should just be tracking user-visible private windows in the parent process (though I guess that's messy for Fenix?

Flags: needinfo?(jhofmann)

Looks like switching to the new user interface in Firefox 89+ fixed the issue.

Can confirm this was fixed in 91.

Fix window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=380804a8d81c48a7bfc67150207acf76cf35dd5e&tochange=55f827545de27e7c0545046a40fd95fea6254b69

Fixed by Bug 1701303.

Status: NEW → RESOLVED
Closed: 4 years ago
Depends on: 1701303
Flags: needinfo?(jhofmann)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.