Open Bug 503564 Opened 12 years ago Updated 4 years ago
Hide "Save and Quit" button if user pref is to NOT save private data
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/2009060215 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.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
Strangely enough, I couldn't find a dupe so confirming. Seems like the sensible thing to do.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
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.
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)
(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.
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).
Duplicate of this bug: 504580
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?"
(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
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?"
Duplicate of this bug: 505117
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").
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.
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?
(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.
Alex: what should we do here? I'd be able to create a patch that hides the button.
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.
invalid due to Bug 592822?
now that it has landed, invalid due to Bug 592822?
(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.
(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:18.104.22.168) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
(In reply to comment #22) > Still a common issue? Yep.
(In reply to comment #24) > (In reply to comment #22) > > Still a common issue? > > Yep. See https://bugzilla.mozilla.org/describekeywords.cgi#common-issue+
This still happens but I think people are used to this behavior now so it's not getting the traffic it used to.
(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.
I agree it may be worth fixing but it's no longer a common-issue
(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.
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.
Ah, sorry my bad.
(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.
You need to log in before you can comment on or make changes to this bug.