503564 - Hide "Save and Quit" button if user pref is to NOT save private data

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Mattias]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

When closing the browser, the user may see a dialog with a "Save and Quit" button. If using this feature while having "Always clear private data..." checked then the session cannot be restored properly, and a blank page will be displayed.

This bug is filed to solve the root cause of Bug 398817

Reproducible: Always

Steps to Reproduce:
1. Make sure "clear private data" option is checked
2. Open two tabs
3. Close the browser, click Save and Quit
4. Open the browser again
Actual Results:  
The session is not restored

Expected Results:  
Never seeing the "Save and Quit" button at all, and never seeing the old session

Comment 1

[Nochum Sossonko [:Natch]]

Strangely enough, I couldn't find a dupe so confirming. Seems like the sensible thing to do.

Comment 2

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

There are a bunch of bugs that are related & say much the same thing. I think bug 443396 may cover this under the general "reorganization". I wouldn't say it's a dupe, but if/when that stuff gets reorganized this will likely become invalid.

Comment 3

[Brian Mathis]

I agree this is a good UI thing to change, but it is not the root cause of Bug 398817.  The cause of that bug is a fundamental misalignment of what users expect to happen and what actually happens (they expect the more specific thing to take precedence over the less specific thing)

Comment 4

[Mattias]

(In reply to comment #3)
> I agree this is a good UI thing to change

Yay! Thank you, thank you, thank you! Sorry I probably filed this bug incorrectly but I hope this can get fixed. You get the idea.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Oh wow, I just realized this is why Session Restore never works for me at work by reading this bug report.  I always figured it was one of our in-house extensions that broke it.  Yeah I agree that this definitely needs to be implemented if 398817 is going to remain WONTFIXed (and I do see the valid reasons for doing so).

Comment 7

[bmccann]

It's not clear to me how the reporter's expected results differ from the current behavior.
The behavior that I would expect is to see the dialog that says "You are about to close X tabs. Are you sure you want to continue?"

Comment 8

[Mattias]

Attachment: Screenshot of "Save and Quit/Quit/Cancel" dialog

Comment 9

[Mattias]

Attachment: Screenshot of "Close tabs/Cancel" dialog

Comment 10

[Mattias]

(In reply to comment #7)
> It's not clear to me how the reporter's expected results differ from the
> current behavior.
> The behavior that I would expect is to see the dialog that says "You are about
> to close X tabs. Are you sure you want to continue?"

That is the behavior if you *have other FF windows open*.  However, if you are
closing *the last instance of FF*, then you get a different message (as reported).  When you follow the "steps to reproduce",
make sure you have no other FF windows open.

I have attached a screenshot of the reported dialog
Also available here: http://yfrog.com/3oclipboard01aj

The other screenshot is what happens if you do have another FF window open.  This IS what I expected to see if I have the clear private data pref set.
Also available here: http://yfrog.com/0mclipboard02vxuj

Comment 11

[bmccann]

Ok, sounds like we are in agreement on the expected results.  We should see:
"You are about to close X tabs. Are you sure you want to continue?"

Comment 13

[Marcus P S]

I created <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=505548">Bug 505548</a> as well, which is closely related to this problem -- basically, I think that the preference options should be changed as well, and they should ensure that the user is made aware of the contradiction between options, instead of deciding what is a "reasonable" priority of options (which may be not universally "reasonable").

Comment 14

[Jesse Ruderman]

Instead of hiding the button, could we make it work?  I think it's perfectly reasonable for a user to generally want Firefox to not save data, but want the ability to save a session occasionally.

Comment 15

[Damith]

I realized this only after losing some opened tabs after closing a FF session.

*) Won't it be better to DISABLE the "Save and Quit" button (i.e. without hiding) on the said dialog box. 
If space permits a small message can be added indicating that the session cannot be saved because of the privacy setting. 
This would allow the user an opportunity to change the setting and save the session. 
*) Jesse's suggestion appears more convenient. 
In that case, it's good to warn that the user may opt to save the session in concern contrary to the privacy settings.

Either would be beneficial because even privacy concerned users occasionally find saving certain sessions useful.

*) I have another unrelated suggestion (on saving the tabs; not all session data): 
Firefox Sync can be configured to save the opened tabs; but it does not have an option, say, to "View the Tabs from This Computer". 

Such an option would be redundant when Firefox is up and running;
but it may be of use at the time of exiting and reloading Firefox.

I'm suggesting that the users be provided an option (in the said dialog box) to save the opened tabs to Firefox Sync on closure. 
Firefox Sync can automatically restore the tabs (or preferably provide an option to restore them) once it connects to the User account.
This would be secure; and generally as convenient as saving a session (even though session cookies etc. won't be stored).

I know the users can manually sync the tabs even now; but they do not get to reload them from the same computer. Do they?

Comment 16

[Mattias]

(In reply to comment #14)
> Instead of hiding the button, could we make it work?  I think it's perfectly
> reasonable for a user to generally want Firefox to not save data, but want the
> ability to save a session occasionally.

Take a look at the mess of bug 398817.  This is the reason we just need to hide the button if the user pref is to not save private data.  Trying to do anything else will give you hundreds of bug comments with nothing done to fix the problem.  That said, nobody is working on this anyway.

Comment 17

[Michael Kohler [:mkohler]]

Alex: what should we do here? I'd be able to create a patch that hides the button.

Comment 18

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

In terms of UI, we should not ask this question if the user has set the pref to never remember history.  If that happens in this bug, or in a larger reorganization (as zpao mentions in comment #2), I really have no idea.

Comment 19

[eyal gruss]

invalid due to Bug 592822?

Comment 20

[eyal gruss]

now that it has landed, invalid due to Bug 592822?

Comment 21

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #20)
> now that it has landed, invalid due to Bug 592822?

No, the dialog still exists, it's just that we've hidden it by default.

Comment 22

[Nochum Sossonko [:Natch]]

Still a common issue?

Comment 23

[Mattias]

(In reply to comment #22)
> Still a common issue?

Yes, happens every time.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)

Comment 24

[Kartik Agaram]

(In reply to comment #22)
> Still a common issue?

Yep.

Comment 25

[Nochum Sossonko [:Natch]]

(In reply to comment #24)
> (In reply to comment #22)
> > Still a common issue?
> 
> Yep.

See https://bugzilla.mozilla.org/describekeywords.cgi#common-issue+

Comment 26

[[:Cww]]

This still happens but I think people are used to this behavior now so it's not getting the traffic it used to.

Comment 27

[Kartik Agaram]

(In reply to comment #26)
> This still happens but I think people are used to this behavior now so it's not
> getting the traffic it used to.

I'm probably stating the obvious, but that doesn't mean it isn't worth fixing.

The way I've gotten used to this behavior is to not use private mode, and manually clear my history when I remember. And I think of this bug everytime I do that.

Comment 28

[[:Cww]]

I agree it may be worth fixing but it's no longer a common-issue

Comment 29

[Kartik Agaram]

(In reply to comment #28)
> I agree it may be worth fixing but it's no longer a common-issue

Common measured how? I just gave you an example of routing around the problem.

You can prioritize this bug as you like, but I don't see any evidence that it is more (or less) uncommon than when it was created. If you do, please elaborate.

Comment 30

[[:Cww]]

The common-issue flag is used for when something is very commonly reported on support.mozilla.com.  It was marked this way two years ago (probably when we introduced private browsing) as it was confusing a lot of users then.

We haven't seen any complaints of it recently, hence it's been un-flagged.

Comment 31

[Kartik Agaram]

Ah, sorry my bad.

Comment 32

[Mattias]

(In reply to comment #30)
> The common-issue flag is used for when something is very commonly reported on
> support.mozilla.com.  It was marked this way two years ago (probably when we
> introduced private browsing) as it was confusing a lot of users then.
> 
> We haven't seen any complaints of it recently, hence it's been un-flagged.

I originally reported this bug.  It does not have to do with private browsing, but is meant to offer a solution to Bug 398817. Bug 398817 gets a lot of traffic, and is (I think correctly) WONTFIX.  However, fixing bug 503564 (this one) would resolve the root cause of why people keep running into Bug 398817.  If my count is correct, there are 42 duplicates of Bug 398817, and many angry words in the comments.  Just my two cents.