We should change the default time period in Clear Recent History from everything to 1 hour. A lot of users will start to use this dialog coming in from about:private browsing, and we should err on the side of minimizing data loss.

Whether or not most users will come from Private Browsing, I agree that we should opt for minimal deletion. (also note: the time range is *not* used when clearing history on shutdown; when the pref is set to clear history on shutdown, it gets rid of it all)

Ain't nothing to it.

Ok, so, I'm not sure on the best way to handle this, for a few reasons: * Existing users, especially those with the "ask before clearing" pref disabled, won't expect this, and will leave data behind without necessarily having obvious feedback that it is the case. * There's no good way to detect "existing user of CPD" * I don't think we should have different defaults depending on invocation path, so we can't just fudge around this by defaulting differently if invoked from about:privatebrowsing. If this was a new feature, it'd be a no-brainer. But because it's existing, I'm a lot less sanguine about simply changing the behaviour.

>If this was a new feature, it'd be a no-brainer. But because it's existing, >I'm a lot less sanguine about simply changing the behaviour. I am exceedingly sanguine, people weren't using clear private data because they actually wanted to nuke everything all of the time, they were using it because private browsing didn't exist. I don't just want to give them the solution, I want to take away (or at least obfuscate) the problem.

(In reply to comment #4) > >If this was a new feature, it'd be a no-brainer. But because it's existing, > >I'm a lot less sanguine about simply changing the behaviour. > > I am exceedingly sanguine, people weren't using clear private data because they > actually wanted to nuke everything all of the time, they were using it because > private browsing didn't exist. I think that's a false assertion in many cases. You're talking about a feature which has a lot of users across three major releases, and making assumptions about how they used the feature. You're also assuming that users will discover the change, understand the nature of the change, and switch to Private Browsing. Just because we added a new way to skin the cat doesn't mean we can blithely break the old way.

(In reply to comment #3) > Ok, so, I'm not sure on the best way to handle this, for a few reasons: > > * Existing users, especially those with the "ask before clearing" pref > disabled, won't expect this, and will leave data behind without necessarily > having obvious feedback that it is the case. This is a good point, but made moot by bug 463186 which will see us deprecate "ask before clearing" and remove the UI. > * I don't think we should have different defaults depending on invocation path, > so we can't just fudge around this by defaulting differently if invoked from > about:privatebrowsing. See bug 463180. Only the "Clear Recent History" command (invoked from the menuItem, the button on the Private Browsing session start page, or the keyboard shortcut on Windows) will ask about time ranges. When the user sets their browser to clear private data on shutdown, it always does a "for all time" nuke of the selected items.

(In reply to comment #6) > (In reply to comment #3) > > Ok, so, I'm not sure on the best way to handle this, for a few reasons: > > > > * Existing users, especially those with the "ask before clearing" pref > > disabled, won't expect this, and will leave data behind without necessarily > > having obvious feedback that it is the case. > > This is a good point, but made moot by bug 463186 which will see us deprecate > "ask before clearing" and remove the UI. Unless we remove the pref completely, it's not moot, we're just not bothering to support that existing use-case. If we're using that as a way around this, let's remove it, not deprecate it. > > * I don't think we should have different defaults depending on invocation path, > > so we can't just fudge around this by defaulting differently if invoked from > > about:privatebrowsing. > > See bug 463180. Only the "Clear Recent History" command (invoked from the > menuItem, the button on the Private Browsing session start page, or the > keyboard shortcut on Windows) will ask about time ranges. When the user sets > their browser to clear private data on shutdown, it always does a "for all > time" nuke of the selected items. I mean that the original argument is that we'll expose this to users from the start page and these will be new users. That said, if we kill the "don't ask" pref so that those users get the dialog and have a chance to figure this out without RTFM, I'm probably ok with this.

>if we kill the "don't ask" pref so that those users get the dialog >and have a chance to figure this out As far as I understand, there is no longer a situation where we would want to clear data when the user clicks a button or menu item, without first showing them the Clear Recent History dialog box.

So, to sum up, we have two choices here: 1) Land this patch to change the default to 1 hour 2) Leave it as-is. The downside to changing it is that people who currently use "clear without prompting" mode will be surprised into leaving data around. Bug 463186 has a patch to remove the UI for that pref, but a) that hasn't landed, b) that's the UI, not the code paths that use the pref, c) that bug is non-blocking, whereas this one is, currently. The downside to leaving things as-is is obviously that some users will experience data loss if they don't realize what they're doing when they launch this dialog. Because we've made the dialog more visible, goes the argument, this risk is higher than it used to be. I'll be honest, I like biasing towards less data loss, but this is a dialog designed to erase data you don't want kept around, so I don't love changing it under existing users (who count on it to delete everything) in the name of would-be new users who don't count on it to do anything yet. The behaviour those existing users are counting may be transitioning to "unsupported" with the removal of the pref, but that's not a good reason to be flippant about it, particularly since it might be a hard behaviour for them to notice (they probably just trust us to continue doing this properly). If we leave it as-is, new users will either blow through it, deleting everything without meaning to (bad), or they will discover the functionality and make a choice, after which point the dialog will persist that choice as the default. If it weren't for the memory, if we were always resetting to deleting everything, I would consider THAT a blocking bug because conscientious users could nonetheless be bitten by this. This bug I consider much more borderline, and I'm not really convinced that a new user who, incited by the private browsing page to discover this new functionality, will blindly click through it, the way they do with task-interrupting security dialogs that they don't ask for, understand, or expect. In short, then: I think the risk we are trying to mitigate does not clearly outweigh the risk we are introducing. I think we should leave the bug open to come to an agreement, but I don't think changing it as described should block Firefox 3.1. Re-nominating.

Umm, bug 469158 landed, and unless I'm missing something here, it's a dupe of 463186. So there is no option to "ask before clearing..." anymore.

From bug 469158 comment #20: > > so if i understand you the new behavior is: > > > > - Tools > Clear Recent History... - Always show the UI > > - about:privatebrowsing clearing your recent history - Always show the UI > > - clear private data on exit - NEVER show the UI > > > > is that true ? > > Yes. In other words, the "clear without prompting mode" is gone, so there should be no problem in changing the default time period. This doesn't affect "clear private data on exit", which always clears everything.

(In reply to comment #10) > Umm, bug 469158 landed, and unless I'm missing something here, it's a dupe of > 463186. So there is no option to "ask before clearing..." anymore. Mmm - so it had. I *thought* I remembered reading review comments on that patch... Okay, so the risk to existing users of having data linger around without their realizing it is significantly lower now, and since in both cases the risk is now the same ("person failed to notice the combo box, with unexpected results") and the mitigation is now the same ("the dialog will remember your preferred setting.") comment #7) > (In reply to comment #6) > > This is a good point, but made moot by bug 463186 which will see us deprecate > > "ask before clearing" and remove the UI. > > Unless we remove the pref completely, it's not moot, we're just not bothering > to support that existing use-case. If we're using that as a way around this, > let's remove it, not deprecate it. Given the above, and your argument here, I think this patch is now fine as-is. mconnor, what do you think?

>the risk to existing users of having data linger around without their >realizing it is significantly lower now Yeah, we clear without bothering the user, so one way of looking at it is that this dialog doesn't have any existing users yet, it is (kind of) a new dialog with a new purpose an a new name. >in both cases the risk is >now the same ("person failed to notice the combo box, with unexpected results") If we think accidental data loss is equal to accidental data preservation. However size of the data in question differs: In the accidental data preservation fail state they might accidentally keep a few random Web sites they went to. Getting these to show up in the awesome bar requires some form of string match. Also, if they were expecting it to clear everything, they probably clear everything regularly, so they will take the data out next time. There is undo for accidental data preservation. In the data loss fail state, they wanted to clear a few sites, and end up destroying their entire awesome bar. There is no undo. >mitigation is now the same ("the dialog will remember your preferred >setting.") Given the undoable nature of data loss, and our intent to have this be a regularly used tool for retroactive private browsing, I'm pretty hesitant to let the UI stick on "clear everything." Of course that at least means that they have selected the option once, so the next time they will have less to lose. What about this, we let the UI stick, but we also check how much stuff we are about to delete. If we 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 (but reset the browser when they first got their used computer).

Filed bug 472211 to discuss options for preventing unintentional data loss.

Comment on attachment 349469 [details] [diff] [review] default to 1 hour yeah, my objections are covered now.

Landed on mozilla-central for baking http://hg.mozilla.org/mozilla-central/rev/e3796dbb6de7

Doesn't block, but wanted+ and I'll happily approve the patch tomorrow if it bakes successfully.

Comment on attachment 349469 [details] [diff] [review] default to 1 hour a191=beltzner

Fixed on branch. http://hg.mozilla.org/releases/mozilla-1.9.1/rev/099b54995426

verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090120 Minefield/3.2a1pre and the equivalent nightly on Windows Vista. The last hour is now the default.

Verified on 1.9.1 branch with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre ID:20090204020327 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre

https://litmus.mozilla.org/show_test.cgi?id=7666 added to Litmus.