Closed Bug 472211 Opened 16 years ago Closed 13 years ago

Attempt to prevent massive data loss with new Clear Recent History interface

Categories

(Firefox :: Private Browsing, defect, P4)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: faaborg, Unassigned)

References

Details

The new Clear Recent History window was designed to be a counter part of private browsing, but in reverse, where the user selects a small amount of time (like an hour or 2) that they want to clear.

However, this dialog box is very similar in name, menu position, and appeared functionality to the previous "Clear Private Data" that some users leveraged to regularly destroy everything that the browser had ever collected.

The user's of the previous interface will likely want to be able to continue to regularly clear everything that the browser has collected manually, however this creates a significant potential problem for new users:

1) user gets a used computer and clears all of the data in Firefox
2) user uses Firefox for three months
3) user attempts to clear the last few hours of browsing, but accidentally deletes three months worth of data because the pref stuck to "everything" from step 1.

One way to try to make both sets of users happy would be to detect that more than a week or two (or some other larger threshold) of history is about to be destroyed, we add an additional confirmation.  This allows users of the previous dialog to have a somewhat similar interface (since they use the interface faster than the threshold we set), and helps to reduce the number of users who accidentally nuke their browser when they were actually just trying to clear a few hours.

Another option would be to expire the pref sticking after a certain amount of time.  This is more unconventional, but would avoid us having to show a modal confirmation dialog.  The downside is that users may occasionally feel that the interface is non-deterministic.
OS: Mac OS X → All
Hardware: x86 → All
How about not remembering that pref at all, and each time the dialog is invoked, just default to the shortest time span available?
Yeah, I think that would be a fine solution as well.  Some users will want to regularly manually delete all information, and will find that behavior annoying.  However, if they really should be regularly manually deleting all information (instead of using the two kinds of automatic removal we built in), is debatable.
I'm still thinking it through, but I think I disagree with Ehsan's suggestion in comment 1. Keeping memory for the pref allows this dialog to serve both constituencies (clear a little, clear all) pretty well, and only results in data loss when users switch between modes, which is something I think is sort of contrived.  It *could* happen, absolutely, and users could open the history sidebar, select all, and delete.  But forgetting that pref stands to annoy a lot of people in favour of an edge case.

Warning on mass-delete I'm less opposed to - it still feels like a prompt that's going to annoy some users, but if we're smart about the threshold then even users who habitually delete everything will never see it (since they are unlikely to ever end up with more than, say, a month's worth of history accumulated.)  At that, we might still get calls to add a "don't doublecheck in future" pref, but both of those feel like better balance than forgetting the timespan setting, which I'm almost certain I'd be annoyed with.
Any status updates here?
I don't think this is really critical, though the warning would be potentially useful with the right threshold, as Johnath notes.
Priority: -- → P4
Target Milestone: --- → Future
Depends on: 480169
I'm going to go out on a limb here and mark this as RESOLVED WONTFIX.  The current behavior seems unlikely to lead to harmful habituation; the scenario in the original report would require not using the dialog for months and then suddenly popping it up and quickly accepting it without reading it.  Furthermore, the time window for confusion with the old "Clear Private Data" dialog has long since passed.

Feel free to reopen if you still consider this an issue.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.