Still possible to open windows at about:privatebrowsing from the Windows Task Tray menu when in perma-PB mode.
Categories
(Firefox :: Private Browsing, defect, P3)
Tracking
()
People
(Reporter: mconley, Unassigned)
References
Details
Attachments
(1 file, 2 obsolete files)
I was speaking with a friend over the weekend who described the following bug:
- She launches Firefox
- She logs into her Google Account from a normal browser window
- She then opens a Private Browsing window, and navigates it to google.com
- The Private Browsing window is already logged into her Google account
Reporter | ||
Comment 1•2 years ago
|
||
The reporter also says this has been happening to them for about a year.
Hey Christoph, overholt suggested you might be the right person to point at this. Any idea what's going on? I'm happy to be the go-between with the reporter - she's a personal friend who's quite responsive.
Reporter | ||
Comment 2•2 years ago
•
|
||
One thing that's interesting in that video I saw is that soon after reaching Google from her Private Browsing window, the reporter gets shown a little panel in google.com that tells her that they've noticed she hasn't logged in in 6 months.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
From the about:support
data I can see that browser.privatebrowsing.autostart
is enabled. That means all browser windows are in private browsing mode and share a data bucket. You can test this yourself in a new profile if you enable permanent PBM via the pref and restart the browser. There will be no difference between normal and private browsing windows anymore.
What's unexpected here is that opening a new private browsing window is still possible. In permanent PBM all windows should look like normal windows. It might have to do with the private browsing window being launched from the app shortcut. I can't reproduce this exact issue because I only have a Windows 11 test machine currently, which doesn't show me this context menu at all.
Ideally we'd have the capability to spawn multiple isolated private browsing sessions, e.g. via incrementing the privateBrowsingId
that is part of OriginAttributes
. In reality a lot of components still make the assumption that there is only one private browsing store. They'd have to be updated to account for multiple stores.
Ben, could your recent changes to how we launch private browsing windows via app-shortcut have regressed this?
Comment 4•2 years ago
|
||
Ok I can reproduce now. Opening PBM via the app shortcut while permanent PBM is enabled opens a PBM window on about:privatebrowsing. This is unexpected and makes the UX confusing. Opening the PBM window via the main menu doesn't behave this way.
Comment 5•2 years ago
|
||
Bug 853996 changed that we don't open about:privatebrowsing when permanent PBM is enabled.
Opening PBM via menu item calls OpenBrowserWindow
in browser.js
which accounts for permanent PBM: https://searchfox.org/mozilla-central/rev/0d7e190891e62276cf934cc0b96b22e8e086ddb9/browser/base/content/browser.js#4602-4605
Opening PBM via commandline (and shortcut) uses openBrowserWindow
in BrowserContentHandler.jsm
and unconditionally opens about:privatebrowsing
: https://searchfox.org/mozilla-central/rev/0d7e190891e62276cf934cc0b96b22e8e086ddb9/browser/components/BrowserContentHandler.jsm#548
Mike, unless there are any other concerns, can we make this bug public? You might want to remove the attachments (video + support data) if the reporter isn't willing to share that publicly.
Comment 6•2 years ago
|
||
(In reply to Paul Zühlcke [:pbz] from comment #3)
From the
about:support
data I can see thatbrowser.privatebrowsing.autostart
is enabled. That means all browser windows are in private browsing mode and share a data bucket. You can test this yourself in a new profile if you enable permanent PBM via the pref and restart the browser. There will be no difference between normal and private browsing windows anymore.What's unexpected here is that opening a new private browsing window is still possible. In permanent PBM all windows should look like normal windows. It might have to do with the private browsing window being launched from the app shortcut. I can't reproduce this exact issue because I only have a Windows 11 test machine currently, which doesn't show me this context menu at all.
Ideally we'd have the capability to spawn multiple isolated private browsing sessions, e.g. via incrementing the
privateBrowsingId
that is part ofOriginAttributes
. In reality a lot of components still make the assumption that there is only one private browsing store. They'd have to be updated to account for multiple stores.Ben, could your recent changes to how we launch private browsing windows via app-shortcut have regressed this?
It looks like you may not need me at this point, but since we're looking into this area I'll note that the most relevant part of my work here are patches like https://phabricator.services.mozilla.com/D139988 and https://phabricator.services.mozilla.com/D149908 that ensured we were setting the private
feature when opening private windows correctly. I would be somewhat surprised if this broke things since we already did that in a bunch of other places, but I don't know the code well enough to say that with certainty.
Comment 7•2 years ago
|
||
(In reply to bhearsum@mozilla.com (:bhearsum) from comment #6)
It looks like you may not need me at this point, but since we're looking into this area I'll note that the most relevant part of my work here are patches like https://phabricator.services.mozilla.com/D139988 and https://phabricator.services.mozilla.com/D149908 that ensured we were setting the
private
feature when opening private windows correctly. I would be somewhat surprised if this broke things since we already did that in a bunch of other places, but I don't know the code well enough to say that with certainty.
Thanks for checking Ben! I've tested some older versions via mozregression and I don't think this is a regression from your work. It could be that this never worked properly to begin with.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 8•2 years ago
|
||
Thanks for the analysis in here! I've conveyed to the reporter how she can revert back to the default configuration. That seems to have solved it.
I've restricted access to the video, but she said sharing the about:support information is fine.
Reporter | ||
Comment 9•2 years ago
|
||
As this turned out to be an issue of user confusion in a non-default configuration, I think we can open this bug. I'm going to update the bug summary to more accurately reflect what the real issue is here.
STR:
- In about:preferences, go to Security & Privacy, scroll down to History
- Change the dropdown to "Use custom settings for history" and check the "Always use private browsing mode"
- Restart the browser
- Right-click on the Firefox icon on the Windows task tray
ER:
"New private window" should not be an option listed in the Windows task try menu for Firefox when in permanent PB mode.
AR:
"New private window" menu item exists and opens a window at about:privatebrowsing.
Reporter | ||
Updated•2 years ago
|
Comment 10•2 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) from comment #9)
As this turned out to be an issue of user confusion in a non-default configuration, I think we can open this bug. I'm going to update the bug summary to more accurately reflect what the real issue is here.
STR:
- In about:preferences, go to Security & Privacy, scroll down to History
- Change the dropdown to "Use custom settings for history" and check the "Always use private browsing mode"
- Restart the browser
- Right-click on the Firefox icon on the Windows task tray
ER:
"New private window" should not be an option listed in the Windows task try menu for Firefox when in permanent PB mode.
AR:
"New private window" menu item exists and opens a window at about:privatebrowsing.
If this is referring to the Jump List (context menu on the taskbar when Firefox is open), this might be as simple as tweaking https://searchfox.org/mozilla-central/rev/0d7e190891e62276cf934cc0b96b22e8e086ddb9/browser/modules/WindowsJumpLists.jsm#478 to not add privateWindowTask
when permanent private browsing is enabled.
Comment 11•2 years ago
|
||
(In reply to bhearsum@mozilla.com (:bhearsum) from comment #10)
If this is referring to the Jump List (context menu on the taskbar when Firefox is open), this might be as simple as tweaking https://searchfox.org/mozilla-central/rev/0d7e190891e62276cf934cc0b96b22e8e086ddb9/browser/modules/WindowsJumpLists.jsm#478 to not add
privateWindowTask
when permanent private browsing is enabled.
We also keep the private browsing mode item in the main menu. We can either hide them from both the Jump List and the main menu, or we adjust the code that open the window from the jump list to not open about:privatebrowsing
here when permanent PBM is enabled: https://searchfox.org/mozilla-central/rev/0d7e190891e62276cf934cc0b96b22e8e086ddb9/browser/components/BrowserContentHandler.jsm#548
Reporter | ||
Comment 13•2 years ago
|
||
Per bug 1738027 comment 1, this also affects the Tor Browser folk.
Reporter | ||
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
The severity field is not set for this bug.
:timhuang, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•7 months ago
|
Comment 17•25 days ago
|
||
@mconley we would like the patch you have provided for Tor Borwser. See our most recent upstream issue. Is there any reason why the patch has remained as a draft?
Otherwise it would be great if this could land, or we could borrow it ourselves for use with ESR 128.
Reporter | ||
Comment 18•25 days ago
|
||
Hi! Thanks for reminding me about this one.
So it's been a while since I've worked on this, but leafing through the comments here and looking at the patch, I think there were a few things blocking me from getting it landed at the time:
- I seem to recall there was existing high-priority work going on related to having a separate Private Browsing task tray icon on Windows, and I risked bumping into that a little bit, so I wanted to wait until that work settled
- There was something related to the Jump List involved here, too. It looks like we wanted to remove the Jump List entry for opening private browsing windows if permanent PB mode was enabled. The old Jump List implementation made that difficult, and so I began the (long and arduous) task of refactoring the Jump List backend. That's now been completed (bug 1880082).
I think we should still revisit this and try to get this patch cleaned up and landed. It's missing a few things:
- It obviously needs a rebase. I would be highly surprised if it applies cleanly at all.
- It needs logic to update the Jump List to not include the "New Private Window" jump list item if permanent PB mode is enabled
- It needs tests.
Are you interested in taking that work on, henry-x? I'm certainly willing to mentor you through it, if you'd like.
Comment 19•25 days ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) from comment #18)
I think we should still revisit this and try to get this patch cleaned up and landed. It's missing a few things:
- It obviously needs a rebase. I would be highly surprised if it applies cleanly at all.
- It needs logic to update the Jump List to not include the "New Private Window" jump list item if permanent PB mode is enabled
- It needs tests.
Are you interested in taking that work on, henry-x? I'm certainly willing to mentor you through it, if you'd like.
I'll have to think about how much time I can spend on this. More regarding the Windows Jump List, which I'm not familiar with, and writing a test.
I'll keep my needinfo flag for this, and revisit this once I've got a better idea of my work load for Tor Browser.
Comment 20•3 days ago
|
||
I'm not going to work on the windows Jump List, but I'll work on part of this in bug 1919363.
Updated•3 days ago
|
Description
•