495577 - Rename the "Automatically start Firefox in a private browsing session" checkbox in privacy prefpane to cause less confusion

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect)

Comment 1

[Aaron Train [:aaronmt]]

In Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090529 Shiretoko/3.5pre, when enabling the new pref to automatically start Shiretoko in PB mode, the state of the browser immediately changes to PB mode without prompt. 

This can be very confusing to the end user as naturally they would expect to be returned to the same state prior to entering preferences. The mode changed without prompt.

At bare minimum, a prompt should warn them that changes will take affect upon restart of the browser. 

Is this intended?

Steps to reproduce: 

1. Pull up the preferences menu
2. Privacy Tab
3. Shiretoko will "Use custom settings for history"
4. Checkmark, "Automatically start Shiretoko in a Private Browsing session".

Expected results: Changes take affect on next restart of the browser
Actual results: Browser enters PB mode state.

Unexpected behavior?

Comment 2

[(no longer active)]

This behavior is by design, and was added as part of bug 462041.  I think this is in fact the logical expectation of the user, since all of the preferences in the Options/Preferences window take effect immediately after being confirmed/activated.

Comment 3

[Aaron Train [:aaronmt]]

This is very unsettling. Whereas each different preference in the Options/Preferences window refers to the current, the preference associated with this bug refers to the later (at a time of next full browser restart). 

"Automatically start Shiretoko in a private browsing session" - nowhere in that direction does it refer to the present. 

I for certain was puzzled among alongside other members in today's fx3.5 test day . Certainly it was expected for the browser to change states _on next restart_ not now AND later.

Comment 4

[Aaron Train [:aaronmt]]

With the removal of the title bar indication of private browsing mode and the action performed by selecting this preference, the state of the browser after closing the preferences window is confusing. There is no indication that it did enter private browsing mode at all.

Comment 5

[(no longer active)]

A UI person needs to weigh in on this.  Let's reopen for now...

Comment 6

[Aaron Train [:aaronmt]]

Worst scenario - a user enables this option, and continues to browse for days unknowingly that their browser is already in a private browsing state. They can not disable private browsing mode (it's greyed out after enabling this pref) because they are already in it (without consent) (browser never restarted).

Comment 7

[Aaron Train [:aaronmt]]

If the same behavior were to apply when disabling that pref it would take the browser state out of private browsing mode (still needing a prompt). This does take the browser out of private browsing mode, but why are the tabs I have opened in private browsing mode still open in normal browser state?

Steps to reproduce: 

1. Enable the pref
2. Browser enters PB mode
3. Open tabs and browse in PB mode
4. Disable the pref

Actual results: Tabs from PB mode still open
Expected results: Tabs from PB mode would vanish

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

If the user specifically asks their browser to never remember history, and then clicks ok, how is that not consent?  If we were to require a restart, then we would get data preservation bugs as people started to browse thinking that we were protecting their privacy, when in reality we were not.  We could require a restart, and then add a notification bar that tells the user they have to restart, but that seems like making an easy thing complex for the purpose of complexity.

Comment 9

[Aaron Train [:aaronmt]]

(In reply to comment #8)
> If the user specifically asks their browser to never remember history, and then
> clicks ok, how is that not consent?  If we were to require a restart, then we
> would get data preservation bugs as people started to browse thinking that we
> were protecting their privacy, when in reality we were not.  We could require a
> restart, and then add a notification bar that tells the user they have to
> restart, but that seems like making an easy thing complex for the purpose of
> complexity.

"Never remember history", as an option is inferring for action to be taken at present and in the future (i.e, now and then). 

"Automatically start Shiretoko in a private browsing session", as an option - as I read it is inferring for action to be taken in the future (i.e, no action at present, only on next restart)

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

Ok, I see what you mean (wasn't thinking about the custom settings UI).  Yeah if we weren't way past the string freeze I would recommend that we change that string to reduce confusion.

Comment 11

[Ivan Naitana]

(In reply to comment #8)
> If the user specifically asks their browser to never remember history, and then
> clicks ok, how is that not consent?

I can see the point about doing immediately what the user expressed the wish to do anyway.

But I really don't think that when unchecking the option (like Aaron pointed in #7  and I did in bug 495579) the tabs from the Private Browsing session should be kept open when going automatically out of it.

Comment 12

[Ivan Naitana]

Also, may I point out that when enabling the option as in #1, PB starts automatically as discussed, but the tabs are not resetted as it happens when entering PB in the standard way.

I'd say there are two issues: one with entering PB immediately when enabling the "start in PB mode" option (which could be a feature), and one with keeping the same tabs when enabling or disabling the option, and so automatically entering and exiting PB mode, which is different than the standard behaviour (and for me is a bug).

Comment 13

[(no longer active)]

We deliberately retain tabs when this pref is checked/unchecked, because it would be very weird if all the tabs were closed down when a checkbox is flipped inside the Preferences window (especially on Mac and Linux where prefpane settings take effect right after being activated.)

Comment 14

[Aaron Train [:aaronmt]]

What I draw from this discussion is that there is code to be reexamined and tweaked. At minimum, perhaps a string change and or prompt.

So what are the options/conclusions here? Beltzner? UI? Ehsan?

Comment 15

[(no longer active)]

I'd personally suggest a string change to make what happens as a result of UI actions clearer.  Not important for 3.5 though, I think.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

I agree with Ehsan

Comment 17

[Ivan Naitana]

I still think that the tabs should be resetted when entering automatically PB mode, because it's the main thing PB mode is about and the main thing the user would expect from it.
If you don't want the tabs to be resetted each time you check an option, then it shouldn't go in and out of PB mode each time you check that option.

Anyway, very last thing... when you uncheck the option and click OK (perhaps immediately on linux), you are still on the same page but the page title has disappeared from the title bar. Now, this is finally a glitch, isn't it?;)

Comment 18

[Aaron Train [:aaronmt]]

(In reply to comment #17)
> I still think that the tabs should be resetted when entering automatically PB
> mode, because it's the main thing PB mode is about and the main thing the user
> would expect from it.
> If you don't want the tabs to be resetted each time you check an option, then
> it shouldn't go in and out of PB mode each time you check that option.
> 
> Anyway, very last thing... when you uncheck the option and click OK (perhaps
> immediately on linux), you are still on the same page but the page title has
> disappeared from the title bar. Now, this is finally a glitch, isn't it?;)

File a separate.

Comment 19

[(no longer active)]

(In reply to comment #16)
> I agree with Ehsan

Morphing accordingly.

Comment 20

[Aaron Train [:aaronmt]]

This seems lost, any update?

Comment 21

[(no longer active)]

Alex, any idea for a better string?

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

As I understand it the main concern here is that the user has selected the custom option of "Automatically start in private browsing" and may be confused into thinking that they are now in private browsing mode, as opposed to it coming into effect the next time they start the application.  (please correct me if this is wrong, coming back to this bug after quiet awhile).

The problem with a string change is that we don't want to change the name of the pref based on what state the user is in (they haven't checked it yet, they haven't restarted yet, they have both checked and restarted).

A notification bar similar to the one we use in the addons manager saying that you must restart before the changes come into effect seems like the most direct way to get this message across to the user.  This is also internally consistent with other parts of our UI, and something we might use again in the future if we encounter the same form of problem (even though so far we haven't had to use a restart notificiation bar in options yet).

Comment 23

[Ivan Naitana]

Sorry Alex, but the problem is actually the opposite.

"Automatically start in private browsing" could lead to think PB mode will be effective from the next restart, while instead the option leads immediately into PB mode, without any notice and without refreshing the tabs (which is what usually happens when entering PB mode).
Also, unchecking the option leads immediately out of PB mode, again leaving all the tabs open.

I'd suggest something like "Enable permanent private browsing mode".

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

Ok, the "enable" is referenced by the checked or unchecked state of the checkbox, so perhaps:

[ ] Permanent Private Browsing mode

Comment 25

[Aaron Train [:aaronmt]]

(In reply to comment #24)
> Ok, the "enable" is referenced by the checked or unchecked state of the
> checkbox, so perhaps:
> 
> [ ] Permanent Private Browsing mode

That's better than the current string. It's better because it implies the present and future rather than just the future.

Comment 26

[(no longer active)]

Agreed, patch forthcoming.

Comment 27

[(no longer active)]

Attachment: Patch (v1)

Comment 28

[Dão Gottwald [:dao]]

The access keys seem random... m for "Permanent Private Browsing mode" and p for "Accept third-party cookies"?

Comment 29

[(no longer active)]

(In reply to comment #28)
> The access keys seem random... m for "Permanent Private Browsing mode" and p
> for "Accept third-party cookies"?

I didn't want to change the "p" accesskey, and "m" was the best thing available.  Do you want me to change the existing "p" accesskey?  (Does that need a key change?)

Comment 30

[Dão Gottwald [:dao]]

I think we should use p for "Permanent Private Browsing mode", a for "Accept cookies from sites" and c for "Accept third-party cookies". I don't _think_ the last two changes would need new entity names. Localizers should adjust any access keys as needed. Their conflicts may be completely different from the ones that pop up in en-US.

Comment 31

[(no longer active)]

Attachment: Patch (v2)

With the suggested accesskey changes...

Comment 32

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/4b3e63903f2e

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with builds on OS X and Windows like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090821 Minefield/3.7a1pre ID:20090821030931

Comment 34

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 394727 [details] [diff] [review]
Patch (v2)


>+<!ENTITY  privateBrowsingPermanent.label "Permanent Private Browsing mode">
>+<!ENTITY  privateBrowsingPermanent.accesskey "P">

This change looks really awkward when taken in context of the rest of the options in that dialog, which are all action phrases: "Remember", "Accept", etc.

I think it should, instead, be:

"Always use private browsing mode"

Comment 35

[(no longer active)]

Reopening based on comment 34.

Comment 36

[(no longer active)]

Attachment: Patch (v3)

Comment 37

[(no longer active)]

Comment on attachment 400735 [details] [diff] [review]
Patch (v3)

Alex, do we want to do this?

Comment 38

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 400735 [details] [diff] [review]
Patch (v3)

mostly indifferent but sure, perhaps the Permanent Private Browsing was too much of an alliteration.

Comment 39

[(no longer active)]

http://hg.mozilla.org/projects/cedar/rev/243d48f724f0

Comment 40

[Mounir Lamouri (:mounir)]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/243d48f724f0

Comment 41

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110609 Firefox/7.0a1

Verified issue on Win XP, Win 7, MacOS X 10.6 and Ubuntu 10.10. "Permanent Private Browsing" option was replaced with "Always use private browsing mode".

Setting status to - VERIFIED FIXED.