Closed
Bug 829949
Opened 12 years ago
Closed 12 years ago
Make private browsing friendly with asynchronous session restore collection
Categories
(Firefox :: Private Browsing, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Yoric, Unassigned)
References
Details
At the moment, entering private browsing is a mostly synchronous operation, which depends on collecting the current state of the session.
The ongoing work on bug 829904 is expected to make this collection asynchronous. We'll need to adapt private browsing accordingly.
Comment 1•12 years ago
|
||
Issues regarding global PB are moot in practice now that we have per-window PB in Firefox 20+. Specifically, the code that you're talking about no longer exists anywhere besides Beta and Release. -> WONTFIX.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Comment 2•12 years ago
|
||
(Please file a new bug if you see any performance differences in opening a new private window compared to opening a new regular window. Thanks!)
Reporter | ||
Comment 3•12 years ago
|
||
I am thinking of http://dxr.mozilla.org/mozilla-central/browser/components/privatebrowsing/src/nsPrivateBrowsingService.js.html#l554 is that code somehow dead?
Comment 4•12 years ago
|
||
(In reply to comment #3)
> I am thinking of
> http://dxr.mozilla.org/mozilla-central/browser/components/privatebrowsing/src/nsPrivateBrowsingService.js.html#l554
> is that code somehow dead?
Yes.
Reporter | ||
Comment 5•12 years ago
|
||
In this case, which entry points (or source files?) should I read to find out how it works now?
Comment 6•12 years ago
|
||
With per-window private browsing, there is no need to save any session data before opening a new private window.
Comment 7•12 years ago
|
||
FWIW, the MOZ_PER_WINDOW_PRIVATE_BROWSING is the build time flag that we're using on trunk and Aurora right now.
You need to log in
before you can comment on or make changes to this bug.
Description
•