We probably get one feedback a week related to this, either explicitly asking for support for Firefox's "clear X on quit" prefs or complaining that Reset Camino is too aggressive in deleting things when what they really want is an automated way to clear history, cache, and cookies on quit. I hate to make the Privacy pref pane any bigger, but we probably ought to think about working it in there somewhere. One possible way to do it would be to condense the three "Cookies" radio buttons into a single popup menu and insert a line between Cookies and Passwords (or after Passwords) with wording and layout similar to Firefox's prefs: "[x] Clear personal data on quit [configure]"
Some additional notes since I've been thinking about this lately... Firefox's dialog reads as follows: When I ask Firefox to clear my private data, it should erase: [x] Browsing History [x] Download History [x] Saved Form Information [x] Cache [x] Cookies [x] Saved Passwords [x] Authenticated Sessions As far as I know, we already have a way to do (1), (2), (4), (5), and (6). We don't currently do (3) -- save any form information -- but keep bug 319792 in mind, after which we probably will store this somewhere. Presumably, we save authenticated sessions the same way Firefox does, though I haven't looked at how Firefox "clears" them. In case you're wondering what an "authenticated session" is, there's an explanation here: http://browsers.about.com/od/firef2/ss/firefoxprivate_4.htm According to knowledgeable folks in #developers, authenticated sessions deal with httpauth only, although I don't really expect most Camino users to have any clue what it means. Associated Firefox code is here for future reference: http://mxr.mozilla.org/mozilla/source/browser/modules/Sanitizer.jsm#218 One potentially complicated interaction that we might simply want to punt on is how to handle the case where "clear on quit" is checked and "cookies" is also checked, since that effectively sets "make all cookies session cookies". If something other than (our hidden option for) session cookies is set in the cookie prefs, the UI could potentially be confusing because it will be in a state that doesn't reflect what's going to happen with the cookies on quit. Firefox also allows "Clear Private Data" to be initiated at an arbitrary time, not just on quit, via either a menu item or a button in the prefs window (like what we do with Reset Camino now). The ensuing dialog has its various checkboxes selected in accordance with what was checked in the preferences, and remembers the selection in preferences across uses. Based on the fact that the Core support for Safari-like Private Browsing (bug 251677) is still a work in progress, I think we should look into doing this for 2.0, at least as an interim fix. (I'd personally like to see this stick around as a permanent feature because I think it complements Private Browsing nicely and solves the very nasty bug 174070 as well.)
"Delete all cookies on quit" and "force all cookies from non-whitelisted sites to be session cookies" are not actually the same thing.
Mmm, good point. So there's no UI mess to worry about, then. :)
(In reply to comment #2) > "Delete all cookies on quit" and "force all cookies from non-whitelisted sites > to be session cookies" are not actually the same thing. It later occurred to me that you might have been referring to my assertion that this would solve bug 174070. I think that for the majority of users, the desire for session cookies is fundamentally a privacy concern -- feedback usually indicated users wanted "cookies to be deleted" when they quit the browser -- and that this achieves the desired effect, though it doesn't respect the whitelist. I doubt most of the users who want an easy switch for session cookies care about -- or even know about -- the ability to whitelist certain sites.
Per discussion at this morning's meeting, we'll be going with enhanced reset (bug 405723).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.