Closed
Bug 531825
Opened 15 years ago
Closed 14 years ago
Confirm before clearing private data
Categories
(Firefox for Android Graveyard :: General, defect, P2)
Firefox for Android Graveyard
General
Tracking
(fennec2.0+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0+ | --- |
People
(Reporter: bugzilla, Assigned: mfinkle)
References
Details
(Whiteboard: [strings])
Attachments
(1 file)
2.07 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
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*.
Comment 1•15 years ago
|
||
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 :(
Assignee | ||
Comment 2•15 years ago
|
||
I am staunchly against over-use of confirmation prompts, but this case seems different. I would be fine with adding one here.
Reporter | ||
Comment 3•15 years ago
|
||
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 | ||
Updated•14 years ago
|
tracking-fennec: --- → ?
Updated•14 years ago
|
Assignee: nobody → mark.finkle
tracking-fennec: ? → 2.0+
Priority: -- → P2
Comment 6•14 years ago
|
||
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]
Comment 7•14 years ago
|
||
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
Assignee | ||
Comment 8•14 years ago
|
||
Adds a simple confirmation prompt using Madhava's message.
Attachment #499033 -
Flags: review?(mbrubeck)
Updated•14 years ago
|
Attachment #499033 -
Flags: review?(mbrubeck) → review+
Assignee | ||
Comment 9•14 years ago
|
||
pushed: http://hg.mozilla.org/mobile-browser/rev/194cad6742ea
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Whiteboard: [strings]
Comment 10•14 years ago
|
||
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-testsuite?
Flags: in-litmus?
Comment 11•13 years ago
|
||
https://litmus.mozilla.org/show_test.cgi?id=15205
Flags: in-litmus? → in-litmus?(ioana.chiorean)
Updated•13 years ago
|
Flags: in-litmus?(ioana.chiorean) → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•