Closed Bug 531825 Opened 10 years ago Closed 9 years ago
Confirm before clearing private data
When we press "clear" button in Preferences window in Fennec, private data (cookies/passwords/history) will be removed without any confirmation. People tend to mis-touch the button and they'll lost their cookie/passwords/history. I also think ordinary users cannot understand "private data" includes their history data which is important for their browsing with awesome bar. We should confirm removing or add one more step to make it clear what they'll lost like Firefox for Desktop's dialog. I think this is important problem to make fennec used by general users without their accidental *data loss*.
I agree, I find the current system too error-prone (the button basically wipes out your entire profile, apart from bookmarks). Unfortunately we're past string freeze, so I don't think adding a prompt is really an option now :(
I am staunchly against over-use of confirmation prompts, but this case seems different. I would be fine with adding one here.
If we want to avoid accidental data loss without breaking string freeze, for example, can we use A: slide bar or B: padlock icon or C: add cover here? Case A: slide bar current ui: Clear private data [Clear] new ui: Clear private data [[ -> ] Clear ] or: [[Clear ->] Clear private data] This is just like iPhone. Case B: padlock icon new ui: [LOCK] Clear private date [ ] new ui (when user click [LOCK] icon): [UNLOCK] Clear private date [Clear] # [LOCK], [UNLOCK] is padlock icon, without text label # [ ] is disabled Clear button with gray text label "Clear" In this case, user should click [LOCK] first and click [Clear] button second within a few secondes. If user don't click [Clear] in a few seconds, [UNLOCK] become [LOCK] and [Clear] button is disabled again. This is ui like Mac OS X's preference windows. Case C: add cover for the button new ui: Clear private data [ --> ] new ui (when user slide the button): Clear private data [Clear] In this case, user should slide the button cover with arrow first and then, push the button second. If user don't push the button in a few seconds, button will be covered again. How do you think? Note for most easy options, long-push or double-touch: We need some UI to indicate it and even if we make some icon (?) for long-push or double-touch, user still do it accidentally. The keypoint of the ui is, difficulty to do it accidentally. In case B or C, requiring two different action (click different place or slide+click) we can avoid accidental action.
Assignee: nobody → mark.finkle
tracking-fennec: ? → 2.0+
Priority: -- → P2
Both these approaches make sense. In general, we're trying to use more undo than confirmation as safety mechanisms, but most of the arguments against confirmation (people habituate; extra step every time for a common task vs. an extra step in an uncommon case (like undoing)) don't apply here, so I'd be fine with one. Also, an undo strategy involves keeping all the data around, which is pretty much counter to the whole point of clearing private data For a string, perhaps "Delete all user data, including passwords, bookmarks, and history?" [OK] [Cancel]
Apparently CPD doesn't remove bookmarks, which, to be honest, surprises me -- the model of what it was for, in my head, was "remove traces of my use of the browser." But I guess the distinction is that bookmarks are explicitly made, whereas the rest of this data just accumulates without your explicit permission. so... maybe "Delete your browsing history and settings, including passwords, and cookies?" This also * calls out browsing history, which is the most important thing here * mentions settings, though is vague * mentions passwords and cookies * excludes jargony "data" * avoids referring to the person we're talking to as "user" in the third person
Adds a simple confirmation prompt using Madhava's message.
Attachment #499033 - Flags: review?(mbrubeck)
Attachment #499033 - Flags: review?(mbrubeck) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
verified FIXED on builds: Mozilla/5.0 (Android; Linux armv71; rv:2.0b9pre) Gecko/20101222 Namoroka/4.0b9pre Fennec/4.0b4pre
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus?(ioana.chiorean)
You need to log in before you can comment on or make changes to this bug.