I was speaking with a friend over the weekend who described the following bug:

1. She launches Firefox
2. She logs into her Google Account from a normal browser window
3. She then opens a Private Browsing window, and navigates it to google.com
4. The Private Browsing window is already logged into her Google account

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.

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.

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?

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.

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.

(In reply to Paul Zühlcke [:pbz] from comment #3)

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?

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.

(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.

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.

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:

1. In about:preferences, go to Security & Privacy, scroll down to History
2. Change the dropdown to "Use custom settings for history" and check the "Always use private browsing mode"
3. Restart the browser
4. 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.

(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:

1. In about:preferences, go to Security & Privacy, scroll down to History
2. Change the dropdown to "Use custom settings for history" and check the "Always use private browsing mode"
3. Restart the browser
4. 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.

(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

Per bug 1738027 comment 1, this also affects the Tor Browser folk.

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

For more information, please visit auto_nag documentation.