If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Private Browsing
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: faaborg, Assigned: Ehsan)

Tracking

({verified1.9.1})

Trunk
Firefox 3.6a1
verified1.9.1
Points:
---
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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?").
(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?
(Reporter)

Comment 2

9 years ago
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.
OK then, taking over.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Created attachment 352544 [details] [diff] [review]
Patch (v1)
Attachment #352544 - Flags: review?(mconnor)
Flags: in-litmus?
Duplicate of this bug: 466752
Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.
Component: General → Private Browsing
QA Contact: general → private.browsing
Comment on attachment 352544 [details] [diff] [review]
Patch (v1)

Switching review request to gavin.
Attachment #352544 - Flags: review?(mconnor) → review?(gavin.sharp)
Gavin, could you please provide an ETA on this review?  It should be fairly trivial, I think.
Whiteboard: [has patch][needs review gavin]
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.
Attachment #352544 - Flags: review?(gavin.sharp)
Attachment #352544 - Flags: review+
Attachment #352544 - Flags: approval1.9.1?
Keywords: checkin-needed
Whiteboard: [has patch][needs review gavin]
Target Milestone: --- → Firefox 3.2a1
http://hg.mozilla.org/mozilla-central/rev/9ebcfc4fa401
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Summary: Change the quit dialog box options when the user is in private browsing mode → Hide the quit dialog box when the user is in private browsing mode
Comment on attachment 352544 [details] [diff] [review]
Patch (v1)

a191=beltzner
Attachment #352544 - Flags: approval1.9.1? → approval1.9.1+
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/db57b8e75a87
Keywords: fixed1.9.1
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
File Exit seems to work OK, the session is restored when restarting Minefield after closing out of a PB session.
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?
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.
One more test, using the Dialog to 'Save & Quit' does restore the session. Something is fishy somewhere...
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?
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.
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)
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'.
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!
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.
> 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?
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.
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...
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...
No I haven't, can you cc me on the bug please?
Bug 479994 has been filed to address the issue of the session not restoring when closing using the "X' button.
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.
Keywords: fixed1.9.1 → verified1.9.1
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
Status: RESOLVED → VERIFIED
https://litmus.mozilla.org/show_test.cgi?id=7644 added to Litmus.
Flags: in-litmus? → in-litmus+
Depends on: 502307
You need to log in before you can comment on or make changes to this bug.