1055284 - Buttons in restart warning dialog after changing privatebrowsing autostart in preferences should spell out actions

Status: RESOLVED DUPLICATE of bug 973014

(Firefox :: Settings UI, defect)

Description

[obrufau]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release)
Build ID: 20140818030205

Steps to reproduce:

1. Go to Options
2. Go to Privacy tab
3. Change "Remember history" to "Never remember history", or vice versa.




Actual results:

Firefox displays the modal dialog "Firefox must restart to enable this feature"


Expected results:

The dialog is misleading, because it doesn't say that if you click "OK", it will restart immediately, losing the current session.

Moreover, if you click "Cancel", the preference won't be changed.

I suggest changing it to something like "This feature will be enabled after you restart Firefox. Do you want to restart now?".

And if the user clicks "OK", restart (like now). But if the user clicks "Cancel", Firefox shouldn't close, but browser.privatebrowsing.autostart should change.

Or, even better, the same approach as to add-ons: instead of an annoying dialog, display "This feature will be enabled after you restart Firefox." directly in about:preferences, with a "Restart now" button.

Comment 1

[:Gijs (he/him)]

It's considered good practice to have useful buttons instead, ie have the buttons say "Restart Firefox Now" and "No thanks" or something like this (because the preference doesn't get changed).

Philipp, can you give a better set of messages to use here so we can turn this into a mentored bug? I'm happy to mentor as soon as we have some strings to use.

Comment 2

[:Gijs (he/him)]

(In reply to obrufau from comment #0)
> Or, even better, the same approach as to add-ons: instead of an annoying
> dialog, display "This feature will be enabled after you restart Firefox."
> directly in about:preferences, with a "Restart now" button.

Or this, obviously. But I definitely agree that the current state is imperfect.

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Yes to both of your comments Gijs.
If we have a button (in the UI or in a dialog) it should say »Restart Firefox now«.

If we use a dialog, the second button should actually keep saying »Cancel« since it resets the pref.

I'd prefer the inline approach, but I guess that would create some more engineering questions?

Comment 4

[:Gijs (he/him)]

(In reply to Philipp Sackl [:phlsa] from comment #3)
> Yes to both of your comments Gijs.
> If we have a button (in the UI or in a dialog) it should say »Restart
> Firefox now«.
> 
> If we use a dialog, the second button should actually keep saying »Cancel«
> since it resets the pref.
> 
> I'd prefer the inline approach, but I guess that would create some more
> engineering questions?

More engineering work, yes. Questions, I don't know enough about why this pref forces a restart as it is. Ehsan? Is there some technical difficulty that makes it hard to not immediately restart but just set the pref, and have it take effect on the next restart (providing a button to restart immediately) ?

Comment 5

[(no longer active)]

It's extremely hard for us to support changing the privacy mode of the existing documents when the user changes the setting here.  Without this prompt, if you put Firefox into permanent private browsing mode, we might leak some information in some edge cases until you restart, which is why we had to add this dialog.  The messages could definitely be improved, but this needs to remain a modal dialog I think, because we need to make sure that you will restart your browser immediately if you want the setting change to stick.

Comment 6

[:Gijs (he/him)]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #5)
> It's extremely hard for us to support changing the privacy mode of the
> existing documents when the user changes the setting here.  Without this
> prompt, if you put Firefox into permanent private browsing mode, we might
> leak some information in some edge cases until you restart, which is why we
> had to add this dialog.  The messages could definitely be improved, but this
> needs to remain a modal dialog I think, because we need to make sure that
> you will restart your browser immediately if you want the setting change to
> stick.

I understand the need for the restart, but the idea is, I think, that there should be no expectation of the pref doing anything until the restart - can't we communicate that and suggest the restart, but not make it a modal dialog, as suggested in comment #0 / comment #2 / comment #3 ? For an add-on install to succeed, you also need a restart, but we don't use a modal dialog there either... or is this going to be some kind of strange inbetween state where you're kind of in private browsing mode and kind of not, until you restart? How harmful is that going to be?

Comment 7

[(no longer active)]

The issue is that on OSX, the OS convention is that the setting changes are made immediately as you interact with the controls, so it's not clear to me how to build a UX around that which both makes the setting take effect immediately and makes it not do anything until a restart.  Maybe there are tricks like that, but that seems self-contradictory.

Comment 8

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

This bug seems to be a duplicate of bug 973014.

My suggestion there was to use the following strings:
»Revert« and »Restart $product now«

Not sure which bug to dupe here…

Comment 9

[Askar Safin]

(In reply to :Gijs Kruitbosch from comment #1)
> Philipp, can you give a better set of messages to use here so we can turn
> this into a mentored bug? I'm happy to mentor as soon as we have some
> strings to use.

This is very controversial bug. As you can see there is "just rename buttons" vs "enable deferring changes" battle. So, please, don't turn this bug to mentored one.

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #7)
> The issue is that on OSX, the OS convention is that the setting changes are
> made immediately as you interact with the controls, so it's not clear to me
> how to build a UX around that which both makes the setting take effect
> immediately and makes it not do anything until a restart.  Maybe there are
> tricks like that, but that seems self-contradictory.

OS X Human Interface Guidelines ( https://developer.apple.com/librarY/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines ) says in "UI Element Guidelines: Windows/Dialogs/Accepting and Applying User Input in a Dialog":
> _For the most part_, changes that a user makes in a dialog should appear to take effect immediately.

Note "For the most post". Of course, not all changes should take effect immediately.

(In reply to Philipp Sackl [:phlsa] from comment #8)
> This bug seems to be a duplicate of bug 973014.
Of course, please mark it as duplicate

Comment 10

[(no longer active)]

(In reply to Askar Safin from comment #9)
> (In reply to :Gijs Kruitbosch from comment #1)
> > Philipp, can you give a better set of messages to use here so we can turn
> > this into a mentored bug? I'm happy to mentor as soon as we have some
> > strings to use.
> 
> This is very controversial bug. As you can see there is "just rename
> buttons" vs "enable deferring changes" battle. So, please, don't turn this
> bug to mentored one.

There is really nothing controversial.  We cannot implement the latter very easily so we are just looking for better text for these buttons.

> (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
> comment #7)
> > The issue is that on OSX, the OS convention is that the setting changes are
> > made immediately as you interact with the controls, so it's not clear to me
> > how to build a UX around that which both makes the setting take effect
> > immediately and makes it not do anything until a restart.  Maybe there are
> > tricks like that, but that seems self-contradictory.
> 
> OS X Human Interface Guidelines (
> https://developer.apple.com/librarY/mac/documentation/UserExperience/
> Conceptual/AppleHIGuidelines ) says in "UI Element Guidelines:
> Windows/Dialogs/Accepting and Applying User Input in a Dialog":
> > _For the most part_, changes that a user makes in a dialog should appear to take effect immediately.
> 
> Note "For the most post". Of course, not all changes should take effect
> immediately.

That will be different than all of Firefox's other preferences, so I don't think that is a good idea.  It will also not be obvious to users because they have no way of knowing that the change only has an effect after restarting.