Closed Bug 483541 Opened 15 years ago Closed 15 years ago

minor dataloss if user depending on confirmation for 'clear private data on exit'

Categories

(Firefox :: Private Browsing, defect)

3.5 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WONTFIX

People

(Reporter: guanxi_i, Unassigned)

References

Details

(Keywords: uiwanted)

FF3.1b3 on WinXP

In FF 3.0.x, I had checked the box asking FF to 'Confirm' when 'Clearing private data on exit'. I upgraded to FF 3.1b3 and was testing an elusive bug that depended on my history reaching an elusive state that I couldn't define. Now it had reached that state. I closed FF3.1 to try the places.sqlite file in a fresh profile, expecting to hit 'cancel' when it asked to delete my history. Just imagine my surprise when I discovered this little change between 3.0 and 3.1.

The confirmation was removed in bug 469158. I'm not objecting to that, but the change, as implemented, will cause users who were depending on that confirmation -- whatever their reasons, they have them -- to lose data. It's mostly temporary data, but it kind of sucks.

I can't think of a neat solution, other than warning users 'onfirstexit' that they're about to lose the data, and that they won't be asked again.
Looks like a dupe of bug 483355.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Not a duplicate: That bug wants to reinstate the preference. This bug wants to keep the preference.

I think this bug is pretty clear if you read it, but I'd be happy to clarify anything that is confusing.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*sigh* I meant: That bug wants to reinstate the preference. This bug does not.

Sorry for the spam.
Hmm, OK, so what would the desired behavior be?  I'm thinking that we can check for the old preference at startup, and if it indicates that the user expects the prompt, disable the shutdown clearing pref altogether.  But then again some users may find that strange because the fact that they need to set up the pref again may not be obvious...
How about what I wrote in the description?:

> I can't think of a neat solution, other than warning users 'onfirstexit' that
> they're about to lose the data, and that they won't be asked again.
In that case, on the first exit the user gets prompted, and the time after that she isn't, which may be even more confusing than the first time.

Alex, do you have any suggestions?
Status: REOPENED → NEW
Keywords: uiwanted
That's not what I said. Again, I do not want the original prompt to return.

Simply display the following (or something similar) when they first exit:

   Hi! Your Firefox is configured to delete some of your private data
   every time it exits. If that is what you want, click "Continue". If
   not, click "Cancel" and then click "Tools >> Options >> Privacy" [or
   could we have a link labeled "click here"?] and
   uncheck "Always clear my private data when I close Firefox".

   Please note: You will not see this warning again! If that box is checked,
   from now on, when you exit Firefox, itwill delete the data without asking.

I don't care about that exact wording, but the general idea is there. Perhaps it should be displayed the first time a user exits after checking that box, whether it's the first time they start FF 3.5 of the 100th time.

I don't think it's confusing. While I prefer to minimize dialogs and warnings, there is some dataloss going on here.
Or replace the second paragraph with the usual 'Don't warn me again' checkbox.
BTW, I can see an argument that we can't have a warning or dialog for everything, a la Vista or some software firewall, and we delete much of this 'private data' regularly without a warning, such as cache or history when it expires.

OTOH, users expect those deletions -- browsers have been doing it over 15 years. But if, in their FF 3.0 profile, they checked 'warn me before deleting', then they have a clear expectation that they will be warned.

Maybe it's too unusual a scenario to be worth the resources, but I lean toward fixing it. Otherwise, whoever checked that box will have an unhappy user experience.
Maybe there should be some text next to the checkbox in the privacy prefpane about this (something like "this will erase all your data"), instead of a prompt/larry bar etc. Similar to the idea of emptytext in textfields (i.e. the locationbar).
First-time warnings like this are inherently ineffective, and the annoyance factor will be bigger than any perceived net gain.  It is especially not worth breaking string freeze for ineffective UI.
Status: NEW → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → WONTFIX
(In reply to comment #10)
> Maybe there should be some text next to the checkbox in the privacy prefpane
> about this (something like "this will erase all your data")

Not a bad idea, but that's not for this bug: In this case affected users don't see the privacy prefpane. They check the 'please confirm' box in FF 3.0, upgrade to 3.5, and then lose data when there is no confirmation.


Re: Marking it wontfix and comment #11

I wonder if the warning would be effective in this case, because it appears exactly when the user expects the old FF 3.0 confirmation dialog, but I will leave that to the experts. Maybe there is an alternative solution? Put it in the release notes? Right now, it's tough luck for the affected users, alas.

If this qualifies for release notes, someone tell me (or tell me where that is documented -- searches return only the actual notes) and I'll file a bug.
That would make it even less effective, because users probably don't read that dialog, they just click OK because they are expecting the dialog.  And the net effect is the same on the second run.

I don't know if this is a relnote, we don't relnote every behavioural change, and I don't think this is really changing the overall behaviour much, it just means that for the occasional case where "not yet" is the answer, users won't have that.  I don't think that's a really compelling case, which is why we dropped it in the first place.
You need to log in before you can comment on or make changes to this bug.