814275 - Private browsing not work correctly after opening new window with clicking dock icon

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

+++ This bug was initially created as a clone of Bug #813533 +++

I find a special case which is not fixed in Bug #813533

Enviroment:
*Firefox Nightly 20.
 http://hg.mozilla.org/mozilla-central/rev/4f19e7fd8bea
*Intel Mac OS X 10.8

Step to reproduce:
1) open window 'A' & turn on Private-browsing.
2) close window 'A' (but keep running Firefox in dock).
3) open a new window 'B' with "clicking dock icon".
   if you opened one with context-menu or menubar, this bug does not appear.
4) open a URL in window 'B'.

Result:
The opened URL is recorded in browsing history.

Comment 1

[Josh Matthews [:jdm]]

My suspicion is that this now works in builds compiled from mozilla-aurora tip, given the backout we performed there.

Comment 2

[Josh Matthews [:jdm]]

Sigh. There are a nontrivial amount of places in nsBrowserContentHandler.js that open windows directly and will cause similar breakage (including other situations such as performing a search from the Windows 7 start menu). I'm putting together a patch that sets the privacy status of new windows in nsWindowWatcher based on the global service value.

Comment 3

[Josh Matthews [:jdm]]

Attachment: When the global service matters, force all new windows to conform to the global private browsing state.

I have come to the conclusion that there are far too many ways new windows can be opened in Firefox.

Comment 4

[(no longer active)]

Comment on attachment 684423 [details] [diff] [review]
When the global service matters, force all new windows to conform to the global private browsing state.

Review of attachment 684423 [details] [diff] [review]:
-----------------------------------------------------------------

Sigh.

::: embedding/components/windowwatcher/src/nsWindowWatcher.cpp
@@ +914,5 @@
> +      do_GetService(NS_PRIVATE_BROWSING_SERVICE_CONTRACTID);
> +    if (pbs) {
> +      bool inPrivateBrowsing = false;
> +      pbs->GetPrivateBrowsingEnabled(&inPrivateBrowsing);
> +      isPrivateBrowsingWindow |= inPrivateBrowsing;

Nit: please use if(...)foo=bar; instead of the bit-op here.

Comment 5

[Josh Matthews [:jdm]]

Comment on attachment 684423 [details] [diff] [review]
When the global service matters, force all new windows to conform to the global private browsing state.

I was actually looking for bz's review on this, but thanks.

Comment 6

[(no longer active)]

(In reply to comment #5)
> Comment on attachment 684423 [details] [diff] [review]
>   --> https://bugzilla.mozilla.org/attachment.cgi?id=684423
> When the global service matters, force all new windows to conform to the global
> private browsing state.
> 
> I was actually looking for bz's review on this, but thanks.

Fine, I won't give you generous drive-by reviews any more.  :P

Comment 7

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

(In reply to Josh Matthews [:jdm] from comment #3)
> Created attachment 684423 [details] [diff] [review]
> When the global service matters, force all new windows to conform to the
> global private browsing state.
> 
> I have come to the conclusion that there are far too many ways new windows
> can be opened in Firefox.

I tried your patch. This patch fixes the case which I reported, and following case: opening a new window via opening links other applications when Firefox is in OSX dock.
This patch will fix well. Thank you! (if I find other pattern, then I'll report it immediately.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 684423 [details] [diff] [review]
When the global service matters, force all new windows to conform to the global private browsing state.

r=me

Comment 9

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

I reproduce this bug on Aurora (http://hg.mozilla.org/releases/mozilla-aurora/rev/4e0a8f234a6d).

Comment 10

[(no longer active)]

(In reply to comment #9)
> I reproduce this bug on Aurora
> (http://hg.mozilla.org/releases/mozilla-aurora/rev/4e0a8f234a6d).

Hmm, that's not expected...  Josh?

Comment 11

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

(In reply to Tetsuharu OHZEKI [:saneyuki_s] from comment #9)
> I reproduce this bug on Aurora
> (http://hg.mozilla.org/releases/mozilla-aurora/rev/4e0a8f234a6d).

Sorry, I mistake the bug which I commented.

Comment 12

[(no longer active)]

(In reply to comment #11)
> (In reply to Tetsuharu OHZEKI [:saneyuki_s] from comment #9)
> > I reproduce this bug on Aurora
> > (http://hg.mozilla.org/releases/mozilla-aurora/rev/4e0a8f234a6d).
> 
> Sorry, I mistake the bug which I commented.

Phew!  :-)

Comment 13

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c8766443985c

Comment 14

[(no longer active)]

Josh, we don't need this for Aurora, right?

Comment 15

[Josh Matthews [:jdm]]

Correct.

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c8766443985c

Comment 17

[Tiziana Sellitto [:tiziana]]

Verified fixed on Firefox 20 Beta 5 – 20130313170052:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0