468565 - Hide the quit dialog box when the user is in private browsing mode

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect)

Description

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

When the user is in private browsing mode, the quit dialog will currenlty still ask if they would like to save their tabs.

mconnor suggests that this might be a good time to ask the user if they would like to restart Firefox and load their previous session, or just quit.

After giving this behavior some thought, I think we should quit without using a dialog box when the user is in private browsing mode.  The rationale is that reading the dialog box and making an informed choice imposes a time cost on every user, regardless of what their goal is.  I think in both possible use cases, a series of direct actions will be faster than the conversation and thought involved with a dialog box.  If the user's goal is to quit, not asking is obviously faster.  Also, if the user's goal is to return to their previous session, closing the browser and reopening Firefox might actually be faster than reading the dialog and making an informed choice.

Another significant consideration is that if the user is attempting to close a private browsing window, there is a chance that they might want to close that window rather quickly, in which case a modal dialog box (slightly obscuring what they were looking at) may cause the user to have a strongly negative reaction to our interface, as they are caught by someone looking accessing information that they obviously wanted to keep private ("hey, why are you shopping for rings?").

Comment 1

[(no longer active)]

(In reply to comment #0)
> After giving this behavior some thought, I think we should quit without using a
> dialog box when the user is in private browsing mode.  The rationale is that
> reading the dialog box and making an informed choice imposes a time cost on
> every user, regardless of what their goal is.  I think in both possible use
> cases, a series of direct actions will be faster than the conversation and
> thought involved with a dialog box.  If the user's goal is to quit, not asking
> is obviously faster.  Also, if the user's goal is to return to their previous
> session, closing the browser and reopening Firefox might actually be faster
> than reading the dialog and making an informed choice.

I tend to agree with Alex here.  It's better to give users the ability to undo rather than ask for confirmation.  In this case, undo is as simple as re-opening Firefox.

> Another significant consideration is that if the user is attempting to close a
> private browsing window, there is a chance that they might want to close that
> window rather quickly, in which case a modal dialog box (slightly obscuring
> what they were looking at) may cause the user to have a strongly negative
> reaction to our interface, as they are caught by someone looking accessing
> information that they obviously wanted to keep private ("hey, why are you
> shopping for rings?").

This is a very important point to consider, IMO.

mconnor, what do you think?

Comment 2

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

I asked mconnor in person (he is working out of mountain view this week), and he agreed that we should close without a dialog box.

Comment 3

[(no longer active)]

OK then, taking over.

Comment 4

[(no longer active)]

Attachment: Patch (v1)

Comment 6

[(no longer active)]

Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.

Comment 7

[(no longer active)]

Comment on attachment 352544 [details] [diff] [review]
Patch (v1)

Switching review request to gavin.

Comment 8

[(no longer active)]

Gavin, could you please provide an ETA on this review?  It should be fairly trivial, I think.

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 352544 [details] [diff] [review]
Patch (v1)

This is okay for now.  Can we get this in for b3 still?  Should be safe, but really want feedback on the change.  If it doesn't get to b3, we need a different patch that's Quit/Cancel, since I'm not 100% sure this will be okay.

Comment 10

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/9ebcfc4fa401

Comment 11

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

Comment on attachment 352544 [details] [diff] [review]
Patch (v1)

a191=beltzner

Comment 12

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/db57b8e75a87

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

This does not work right at all. 

STR:
1.  Enter private browsing
2.  open several tabs 
3.  Click the X in the upper right corner 
4.  Restart Minefield from your normal Start Icon 
5.  Note that your previous Session is no more!

Checking under 'History' Restore last - results in dialog box stating session cannot be restored.  

tested using lastest hourly from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1234973172/
Changeset: http://hg.mozilla.org/mozilla-central/rev/9ebcfc4fa401

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090218 Minefield/3.2a1pre  ID:20090218080612

Comment 14

[Jim Jeffery not reading bug-mail 1/2/11]

File Exit seems to work OK, the session is restored when restarting Minefield after closing out of a PB session.

Comment 15

[(no longer active)]

I can't reproduce with the STR in comment 13.  This bug eliminated the quit prompt displayed when exiting the browser from within the private browsing mode, and the session should always be restored (this bug doesn't touch the session restoring code).  Can you reproduce this on a build without this patch?  Can you reproduce this on a clean profile?

Comment 16

[Jim Jeffery not reading bug-mail 1/2/11]

The build before still gives the Dialog box, but when using Quit from the Dialog box while in PB - still results on restart a missing session, so the issue goes back further than this bug.

Sorry for the spam - no time today to play any longer looking for the bustage.

Comment 17

[Jim Jeffery not reading bug-mail 1/2/11]

One more test, using the Dialog to 'Save & Quit' does restore the session. Something is fishy somewhere...

Comment 18

[Tony Chung [:tchung]]

I dont know if this behavior is the right fix.   If you consider the scenario
where your normal browsing mode has multiple tabs open, and then you switch
over to PB mode and open a few more tabs, then you decide to File > Quit in PB
mode, you'll still get the quit dialog box pop up (because of multiple tabs
from normal browsing mode)

however, the user will not remember this quit dialog pertains to normal mode
because they only see the message here show up during PB mode.

Should we change the wording for the quit dialog to emphasize restoring tabs in
the normal mode?

Comment 19

[Tony Chung [:tchung]]

so in layman's repro steps..

1) launch latest shiretoko or minefield, keeping session restore enabled
2) open 2+ tabs in normal mode
3) Switch to PB
4) open 2+ more tabs in PB mode
5) File > Quit in PB mode
6) Verify quit dialog prompt asking to save tabs for next time on PB mode.

Comment 20

[Jim Jeffery not reading bug-mail 1/2/11]

Testing with a Clean profile/ no addons - same behavior - 

Clicking the X in the upper right corner to close the PB session destroys any
previous session you were in when you enter PB via Tools->Start Private
Browsing

Tony, this patch does not display any sort of dialog when exiting PB mode 
no matter how your close it:
file exit
Tools->stop private browsing
X in the uppper corner (windows)

Comment 21

[Jim Jeffery not reading bug-mail 1/2/11]

More testing:

The nightly build from 2/14/09 does not seem to destroy the Session when closing from PB mode using the X and clicking 'quit' on the dialog bog.

The nightly build from 2/14/09 does KILL the session as it does not restart when closing PB from X 'quit'.

Comment 22

[(no longer active)]

I have quite a bit of other patches applied in my build, so the (correct) behavior that I'm seeing may be caused by one of them.  I'm downloading the hourly build you mentioned right now and will look into this tomorrow morning.  Thanks for taking the time to test this!

Comment 23

[Nochum Sossonko [:Natch]]

I can confirm Jim's testing, exiting the app while in pb mode no longer restores the session on startup. Maybe because the session isn't getting properly saved anymore since that function returns false? I'll take a peek around to see how this is handled...

Note, it's not like what happened in bug 476463 where the session was garbage, here the default is loaded (1 page, homepage). I'll give this a try with "load last session" set to see if that is indeed the problem.

Comment 24

[Nochum Sossonko [:Natch]]

> here the default is loaded (1 page, homepage). I'll give this a try with "load
> last session" set to see if that is indeed the problem.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090219 Minefield/3.2a1pre

Confirmed, new bug?

Comment 25

[Marcia Knous [:marcia]]

So the main part of this bug is fixed, which is the fact that the quit dialog does not come up when you exit Private Browsing mode. 

What remains here is to figure out the bug that people are seeing where the regular browsing session is not being restored. Testing on Mac with the latest 1.9.1 nightly, I am not seeing what Natch and others see because if I click the "red" close button, the Firefox session never closes and I remain in PB mode. If I exit in PB mode using the menu item, when I restart the app my previous session is restored.

Using the latest nightly on Linux, I see the same thing that Natch and others are seeing - if I launch a regular browsing session, go to PB mode and click the "X" to close the application, when I restart my previous session is gone and I only have the start page.

I can get a new bug on file to track this issue with closing the app with the x button while in PB mode.

Comment 26

[Nochum Sossonko [:Natch]]

Marcia, your results are expected, Mac doesn't quit the app when you hit the [x] button, at least that's what they say :)

I had a very similar problem with bug 476463, when I used File->Exit all was fine (unless I did it extremely fast, maybe worth a try here as well), however I could reliably hit this bug when I used the [x] button on Vista. I think there's a difference in how well (or in the sequencing) events are pushed between the [x] button and File->Exit...

Comment 27

[Marcia Knous [:marcia]]

Natch: Did you already file a bug for the "X" button issue? If not I will do it right now.

(In reply to comment #26)
> Marcia, your results are expected, Mac doesn't quit the app when you hit the
> [x] button, at least that's what they say :)
> 
> I had a very similar problem with bug 476463, when I used File->Exit all was
> fine (unless I did it extremely fast, maybe worth a try here as well), however
> I could reliably hit this bug when I used the [x] button on Vista. I think
> there's a difference in how well (or in the sequencing) events are pushed
> between the [x] button and File->Exit...

Comment 28

[Nochum Sossonko [:Natch]]

No I haven't, can you cc me on the bug please?

Comment 29

[Marcia Knous [:marcia]]

Bug 479994 has been filed to address the issue of the session not restoring when closing using the "X' button.

Comment 30

[Marcia Knous [:marcia]]

Verified fixed on the 1.9.1 branch using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090224 Shiretoko/3.1b3pre and the latest Windows Vista nightly. I do not receive a quit confirmation dialog when exiting from the PB session (exiting both from the File menu and when closing with the "X'). Adding keyword.

Comment 31

[Marcia Knous [:marcia]]

Verified fixed on the trunk using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090224 Firefox

Comment 32

[Marcia Knous [:marcia]]

https://litmus.mozilla.org/show_test.cgi?id=7644 added to Litmus.