1381866 - Opening a private window opens a normal window instead if initial -private (opened via command line) window was closed

Status: RESOLVED DUPLICATE of bug 1048286

(Firefox :: Private Browsing, defect, P3)

Description

[register]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

1) Close all FF sessions
2) Open a new FF session/window using the -private command line parameter
3) (The private mode window opens)
4) Open a new regular window (either from a shortcut without he -private parameter, or from the File menu)
5) Close the original private window (leave the regular window opened)
6) Open another private window, either from a shortcut with a -private parameter, or form the menu


Actual results:

The new window that's opened in step 6 does not behave like a private window. It's a regular browsing window.

- Browsing history in this window is saved after the browser is closed and re-opened
- The home screen of the newly opened window is the regular FF homepage or a user-set homepage; not the purple-background typical of a private window




Expected results:

The new window that's opened in step 6 should be a private window, not a regular one.

Comment 1

[register]

Note: There's a similar bug filled - #1048286 but it's not the same. This bug indicates that the newly opened window is NOT a private window at all (it saves all the browsing history and does not have the extra privacy features enabled), and not just that it doesn't look like one.

So far reproduces on 2 PCs with Win7 x64 and one Win8.1 x32.

Note2: I had not observed this behavior with previous FF versions, it probably started either with 54 or 53.

Comment 2

[:Gijs (he/him)]

Not a security bug that needs to stay hidden.

Comment 3

[:Gijs (he/him)]

(In reply to register from comment #1)
> Note: There's a similar bug filled - #1048286 but it's not the same. This
> bug indicates that the newly opened window is NOT a private window at all
> (it saves all the browsing history and does not have the extra privacy
> features enabled), and not just that it doesn't look like one.
> 
> So far reproduces on 2 PCs with Win7 x64 and one Win8.1 x32.

Have you tried a clean profile? Can you obtain a full regression window with something like mozregression? ( http://mozilla.github.io/mozregression/ )

Comment 4

[register]

I discovered this first on a new installation of FF, so the profile was clean to begin with. (Later I updated FF on 2 other PCs to 54 and the issue appeared there as well).

I've not tried regression testing as I'm not a developer.

Comment 5

[tobias]

I can confirm this bug with 58beta. A workaround for me was to 
 1) not use `-private` anywhere and 
 2) replace it with `--private-window`
this opens the private window as expected and doesn't break anything else. 

also, I noticed that the man page only shows `-private`, while the help only shows `--private-window`. (tested on ff54 and ff57)

Comment 6

[:Gijs (he/him)]

(In reply to tobias from comment #5)
> also, I noticed that the man page only shows `-private`, while the help only
> shows `--private-window`. (tested on ff54 and ff57)

The man-page is distro-provided and so you should file a bug against the distro, especially if the information provided by the manpage is wrong.

Comment 7

[tobias]

Bugs have been submitted to the two distros I use. 

 * https://bugzilla.redhat.com/show_bug.cgi?id=1334025
 * https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1734975

Maybe Mozilla/Firefox could maintain a man page instead of all the distros themselves? 
Not only those two distros' man page are out of date -- Debian, Arch Linux, CentOS (and therefore likely RedHat Enterprise) among others are also affected as well: 
 * centOS: http://man.linuxtool.net/centos7/u3/man/1_firefox.html
 * Debian: https://manpages.debian.org/unstable/firefox/firefox.1.en.html
 * Arch:   https://manned.org/firefox.1
 * Ubuntu: http://manpages.ubuntu.com/manpages/artful/en/man1/firefox.1.html

Comment 8

[tobias]

I've written a man page (starting from Fedora's). See--> https://bugzilla.redhat.com/attachment.cgi?id=1360974

Comment 9

[Luke Crouch [:groovecoder]]

Marking as P3 to add to the backlog. I can also reproduce this on Mac and Windows with -private command line argument. --private-window works as expected.

The fix here seems to be to deprecate/remove -private and only support --private-window.

Comment 10

[Andrew Overholt [:overholt]]

(In reply to Luke Crouch [:groovecoder] from comment #9)
> Marking as P3 to add to the backlog.

Given this, I'm going to untrack this as regression+affected for 59.

Comment 11

[Rob Wu [:robwu]]

On the current version of Firefox (82), -private forces Firefox into permanent private browsing mode.
The relevant code has not changed significantly since the bug report was created.

I just ran the STR, and the history is not saved, as expected.
The windows don't look like private browsing windows, but that is already covered by bug 1048286.

Comment 12

[Graham Perrin]

I see my bug 1521372 as a duplicate of this bug 1381866.

Bug 1521372 comment #6 tl;dr -p is not synonymous with browser.privatebrowsing.autostart true and so, where bug 1048286 might be viewed as a cosmetic issue, -p truly not working (truly allowing non-private windows) is a privacy issue.

Comment 13

[Graham Perrin]

Above, p was a typo. Apologies for the noise.

-private is not synonymous with browser.privatebrowsing.autostart true