472226 - Attempt to avoid accidental dataloss by removing "saved passwords" from clear recent history dialog (not history and doesn't respect timeframe)

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect, P2)

Description

[Dave Garrett]

Similar premise to bug 472211 but a different potential problem.

The "Clear Private Data" system has been changed to a "Clear Recent History" system. The dialog is more flexible and allows users to selectively clear only portions of their data and thus might be used more often by people who don't want to wipe everything. There's one problem here: the price of an accident can be high. Most people don't back up their data and if one was to wipe everything when they didn't want to it would be quite bad. One way I think would be useful to attempt to avoid mishaps (aside from adding more confirmation for "everything" in bug 472211) would be to remove the saved passwords wiping checkbox from this dialog.

To start, saved usernames and passwords are *not* "recent history". The placement here is a bit odd with this new terminology. I and many users can wipe their entire history, cache, cookies, form autocomplete, etc. and not have it be a horrible inconvenience. Wipe my saved passwords and I'll be annoyed. I can visit pages again and remake cookies and autocompletes, but I can't guarantee I'll remember all my logins that easily. I could easily foresee a user clearing everything intentionally then a long while later coming back here for a quick history cleanup and not noticing that the saved passwords box is checked. It's my opinion that this is more dangerous than it needs to be.

This data is more important, not necessarily relevant to the currently labeled dialog function, and there is already a button to wipe them all in the password manager. I think it should be safe to remove it from here and could potentially save some users a good bit of unnecessary grief.

Comment 1

[Nochum Sossonko [:Natch]]

Then you lose the "catch-all, single location for purging everything firefox knows about me", although I agree that it is *somewhat* odd in the new dialog.

Comment 2

[Dave Garrett]

(In reply to comment #1)
> Then you lose the "catch-all, single location for purging everything firefox
> knows about me", although I agree that it is *somewhat* odd in the new dialog.

It's not that right now anyway. I can't clear my bookmarks or preferences from here either. I think passwords are more in line with that type of data rather than history.

Might be a good idea to have a "nuke my Firefox" wizard added somewhere for the really deep cleaning. (i.e. bookmarks, add-ons, preferences, passwords, various exceptions, etc. plus the regular stuff) Could maybe have a button/link in the history clearing dialog to open this up and thus require extra user interaction to get to the big dataloss.

Comment 3

[Dave Garrett]

Also, big point I just noticed:
passwords: {
      clear: function ()
      {
        var pwmgr = Components.classes["@mozilla.org/login-manager;1"]
                              .getService(Components.interfaces.nsILoginManager);
        // Passwords are timeless, and don't respect the timeSpan setting
        pwmgr.removeAllLogins();
      },

A user would expect to select a timeframe and clear within this timeframe. They can't do this with passwords and it *doesn't* tell them. Unless this can follow the timeframe rules for this dialog I don't see how it can safely be included here. All wipes, even if the user selects 1 hour, wipe ALL passwords. This needs to be changed one way or another.

Comment 4

[Dave Garrett]

Not sure how else you would fix comment 3. Could maybe store dates for when passwords are saved to implement the timeframe. The alternative would be to not implement timeframes and handle them differently, maybe simply disabling this checkbox unless "everything" is chosen.

Seeing as you can tell it to clear a day and it clears everything, the problem is worse than I thought. Raising severity...

Comment 5

[Dave Garrett]

Ah, looks like comment 3 is bug 463343. Nonetheless, I still argue that having this here at all isn't a good idea. Removing it from the dialog altogether would be one possible way to deal with it.

Comment 6

[(no longer active)]

Alex, mconnor, beltzner: any ideas about what we want to do here?

Comment 7

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

Perhaps have the personal data items only appear when the user selects "everything," as additional things you might want to remove?  I agree that it isn't history, but we wanted to keep the functionality around for people who rely on it, the command "clear recent history and personal data" was obviously too long, and wanted to really focus in on what "history" meant (details in bug 464204)

Comment 8

[Mike Connor [:mconnor]]

Not a blocker, but fixing one way or the other would be really good.

Comment 10

[Dave Garrett]

Looks like this is going to be done in bug 480169.

Comment 11

[dlooney601]

I would agree with those that plead for removal of the option to delete saved passwords from this dialog altogether.  

I readily admit to being a klutz, but I've clicked this dialog window way to the right of the actual option boxes when trying to hit the OK button, accidentally activating the saved password options without noticing, and then inadvertanty nuking my saved passwords. I suspect many of the "Firefox deleted my passwords" complaints relate to this happening without ever noticing.

A confirmation is going to make the dialog more cumbersome to use. If someone really wants to delete their saved passwords, going through the edit->preferences->security->saved passwords pathway seems an appropriate safeguard.

Comment 12

[Dave Garrett]

This was done in bug 480169. Passwords are no longer available to clear in the Clear Recent History dialog.

Though, I see some vestigial code left over from this that probably should be removed too. (<preference> in sanitize.xul, passwords functions in sanitize.js, privacy.item.passwords pref stuff, etc.) File another bug for this?

Comment 13

[Dave Garrett]

Cleanup followup filed as bug 490702.

Comment 14

[Nochum Sossonko [:Natch]]

bug 480169 landed on branch...