When leaving private browsing, we set the non-private flag on the existing docshells too soon

RESOLVED FIXED in Firefox 19

Status

()

defect
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

unspecified
Firefox 19
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox18 unaffected, firefox19+ fixed)

Details

Attachments

(1 attachment)

This is a regression from bug 795556.  Here's what happens.  If you leave PB mode when a page is loading, the code at the beginning of _onBeforePrivateBrowsingModeChange sets the docshell flag on everything to false.  Then we call into sessionstore to restore to a blank slate, which means that we'll stop network activity on that tab.  Then the progress monitor code in browser.js sees that, thinks that the network load is done, and sees that there's no favicon loaded, so it calls tabbrowser's useDefaultIcon, which tries to load the {url}/favicon.ico file.  At this point the tab lacks the private bit set, which means that the favicon for that page gets loaded in non-private mode.

This sucks.  These sorts of race conditions will go away once we move away from the global PB mode, but for now we need to set the flag after the sessionstore goof in _onBeforePrivateBrowsingModeChange happens when you're leaving PB mode.
Hmm, doing that does not seem to be enough.  Investigating why.
(In reply to Ehsan Akhgari [:ehsan] from comment #1)
> Hmm, doing that does not seem to be enough.  Investigating why.

That is because the concept of boolean variables is not entirely understood by me.  ;-)
Posted patch Patch (v1)Splinter Review
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #670982 - Flags: review?(josh)
Attachment #670982 - Flags: review?(josh) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/b680d000682f
Target Milestone: --- → Firefox 19
https://hg.mozilla.org/mozilla-central/rev/b680d000682f
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.