If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Per window private browsing observer dnw after using nsIPrivateBrowsingService

NEW
Unassigned

Status

()

Firefox
Private Browsing
5 years ago
5 years ago

People

(Reporter: erikvold, Unassigned)

Tracking

Trunk
All
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

If you try the code here https://gist.github.com/3868985 in scratchpad for a chrome window, then you will not get the 'change' alert, but that would be expected, so I think this is a bug.
Also, in Nightly, https://gist.github.com/3869202 does not produce an alert when setting a window's pb mode to false, which I would expect.  The gist does not produce any alerts on FF 15.
Blocks: 777830
Blocks: 748604
Blocks: 777819
Version: 15 Branch → Trunk
(In reply to Erik Vold [:erikvold] from comment #0)
> If you try the code here https://gist.github.com/3868985 in scratchpad for a
> chrome window, then you will not get the 'change' alert, but that would be
> expected, so I think this is a bug.

This was for FF15 only
nsIPrivacyTransitionObserver dates back to when we didn't have a clear idea on how we will put windows in private browsing mode.  Back in those days, it seemed like what we would need to do is to open a window, then some time after it has loaded, set the usePrivateBrowsing property to true and get it do the right thing.

However, that has changed, and as of a few hours ago that I landed bug 798508, the right way to open a new PB window is to call:

OpenBrowserWindow({private: true})

or alternatively:

window.openDialog("chrome://browser/content/", "name", "chrome,private,...");

This will put the window in PB mode right when it's created and will make it unnecessary to set the usePrivateBrowsing property (in fact, we should consider making that property read-only.)
Now this seems like a bug nevertheless.  Josh, any chance you can take a look into this please?
I guess we can close this as wontfix now?
I still think this is a bug, but I'm curious to know what Josh thinks too.
Flags: needinfo?(josh)

Comment 7

5 years ago
I believe there are two symptoms of the same problem in these snippets: in the first entering private browsing blows away all existing tabs, so I expect that window.gBrowser.docShell refers to two different objects before and after entering PB mode, therefore the observer won't be triggered. In the second one, I doubt that exiting private browsing mode brings back the same dcoshell objects, so window.gBrowser.docShell once against refers to a different docshell than the one that contains the observer.
Flags: needinfo?(josh)
No longer blocks: 748604
You need to log in before you can comment on or make changes to this bug.