Closed Bug 1585306 Opened 5 years ago Closed 4 years ago

After closing the last Private Window, context is not always reset...

Categories

(Firefox :: Private Browsing, defect, P2)

69 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 76
Tracking Status
firefox76 --- fixed

People

(Reporter: thejaka.dev, Assigned: baku)

Details

Attachments

(6 files)

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

Steps to reproduce:

After browsing in Private Windows, possibly with multiple Private Windows open, then after closing all Private Windows, then freshly opening a new Private Window...

Actual results:

I find that sometimes the context from the old private session is reused (cookies are probably not reset). Note: This doesn't always happen, only sometimes. This has been the case for as long as I can remember since I first noticed the issue quite some time back.

Expected results:

Firefox should have started a fresh Private session/context...

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Private Browsing

The priority flag is not set for this bug.
:groovecoder, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(lcrouch)

This shouldn't be the case. Do you have some information that could help us reproduce this problem?

Flags: needinfo?(lcrouch)
Priority: -- → P3

I know of one web page that seems to detect when the page is opened after the first time. It displays a different view the first time, and another view the rest of the time. I was assuming it was purely doing this by checking the cookies but if you're sure all cookies are cleared, it must be doing this in some other fashion. I don't really want to mention the site here because I rather depend on that behavior to tell me if the browser history has been cleared or not, and I'm afraid they might change the page behavior if they figure out it's being used for this purpose :-| Can someone keep a secret?

Ok, tested just now with 71.0 (64-bit) on Windows 10. Open two private windows, close them, then open another and the context persists.

If it still doesn't reproduce, try changing the order of closing. Rather than closing the last opened window first, try closing the first window opened first. Also, if it helps, I have content process limit set to 1.

Here is an STR for this bug:

  1. Create two bookmarks, one named Google with this URL, one named Gmail with this URL.
  2. Use a Firefox Nightly profile with some browsing data. I used my main Firefox profile for reproducing this but it's unclear to me if that's actually needed. In that main profile I had non-private tabs open on both google.com and mail.google.com.
  3. Open a few private windows (I did three). In each one, click on the Google bookmark. Close each window after the Google Search home page is loaded.
  4. Quickly after closing the private windows in step 3, open a new private window. In that new private window (which should now be the only private window open) click on the Gmail bookmark.

Expected Result: The Gmail login page (see screenshot) should be loaded.

Actual Result: The Gmail home page (see screenshot) is loaded.

If you keep devtools network panel open while doing step 4, you will see that a Google NID cookie is submitted to accounts.google.com which causes it to redirect to the Gmail home page. It is unclear where this NID cookie is coming from in the private browsing context. Normally (for example without doing step 3) no such cookie would be sent, and the Gmail login page is loaded.

Andrea, could you please take a look at this, and have a look at where this NID cookie is coming from? This might be a serious bug somewhere... Thanks!

Flags: needinfo?(amarchesini)

Here are the steps I used to reproduce the bug:

  1. Close all instances of Firefox.
  2. Open an instance of Firefox.
  3. Create Bookmarks Google: https://www.google.com/, Gmail: https://mail.google.com/mail/?tab=wm&ogbl.
  4. Clear history, cookies, caches completely.
  5. Close Firefox.
  6. Reopen Firefox.
  7. Open a new Private Window, and open Google in it.
  8. Open another new Private Window, and open Google in it.
  9. Repeat step 8 once more.
  10. Close first Private Window.
  11. Close second Private Window.
  12. Close third Private Window.
  13. Open a new Private Window and open Gmail in it (Using bookmark)

These are more or less the steps that I emailed to Ehsan that initially got a consistent reproduction for me. The additional steps are to exclude possible artifacts. You'll note that I'm clearing the non-Private history, cookies and cache, so the cookie definitely should be coming from a private session. This bug can occur for other sequences of steps (including for only two private Windows, not sure about a single Private Window), but only irregularly, seemingly at random. I'm wondering if nobody noticed this bug before... Ehsan also noticed that the context can spill over when using address bar entries from non-Private session, in a Private Window. I haven't yet tried to reproduce this, but I'm of the opinion that such spilling over of context would breach privacy.

In my opinion, it would be best if the implementation could be changed to provide separate browsing contexts for each Private Window. This is what a user would normally intuitively expect. Sharing context between browsing contexts is an anomaly.

Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Priority: P3 → P2

Is this still UNCONFIRMED?

Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a04554a0abc1
nsILoadGroup and nsILoadGroupChild as builtinclass, r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/622300d893b3
nsILoadGroup observes last-pb-context-exit to monitor the browsing context, r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/decd6e6b3c76
HTTP channels must check if the browsing context is discarded, r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/ceb38b3661bf
private browsing and beacon requests - tests, r=mayhemer

Still not properly fixed: 79.0 (64-bit) Windows 10 2004 Pro. It's better than it used to be, but still infrequently, I get same issue. Occurs somewhat randomly. Haven't yet found the steps to consistently reproduce. After browsing on multiple tabs in private Window, sometimes, after closing and reopening, I find the cookies haven't been reset.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: