These two items appear in the time restricted section of the clear private data window however neither of them actually respond to the time range and instead just clear the data for all time. They should be moved to the lower section.

dataloss as it will delete more data than users expect

This was, if not exactly by design, at least known when the timespan was implemented (see bug 453440 comment 3, for instance). The argument went that, since users ask for these things to be cleared, and we can't do date-based eviction, and neither of them is a thing you explicitly choose to save, overclearing is not a particularly bad thing to have happen. I'm surprised that this blocks. I don't think overclearing cache in particular (whose lifetime we make no promises about) is something we should hold the release for, and I don't really see overclearing of active logins rising to that level either. It's a bug, absolutely, and confusing too. I just wouldn't hold the release for it. In either case, though, we have a couple options: 1) Implement date-based eviction on cache, secretdecoderring, and authmanager 2) Uncheck & disable those checkboxes when a timespan other than "Everything" is selected. In terms of code risk for Firefox 3.1, I think 2 is the sensible option.

I don't know if the proposed solution in comment 0 blocks. I do know that we cannot ship the UI such that it looks like the user is saying "delete the last 4 hours of my cache" and then the entire thing goes kablooie. That *does* block.

(In reply to comment #2) > This was, if not exactly by design, at least known when the timespan was > implemented (see bug 453440 comment 3, for instance). The argument went that, > since users ask for these things to be cleared, and we can't do date-based > eviction, and neither of them is a thing you explicitly choose to save, > overclearing is not a particularly bad thing to have happen. > > I'm surprised that this blocks. I don't think overclearing cache in particular > (whose lifetime we make no promises about) is something we should hold the > release for, and I don't really see overclearing of active logins rising to > that level either. It's a bug, absolutely, and confusing too. I just wouldn't > hold the release for it. > > In either case, though, we have a couple options: > > 1) Implement date-based eviction on cache, secretdecoderring, and authmanager > 2) Uncheck & disable those checkboxes when a timespan other than "Everything" > is selected. Or the option I gave, move them to the data section.

(In reply to comment #4) > (In reply to comment #2) > > In either case, though, we have a couple options: > > > > 1) Implement date-based eviction on cache, secretdecoderring, and authmanager > > 2) Uncheck & disable those checkboxes when a timespan other than "Everything" > > is selected. > > Or the option I gave, move them to the data section. Sorry yeah, I thought I had typed "a couple other options". I don't think I like moving them to the bottom category as much. While it's true that the History category is controlled by the timespan combo where the Data category isn't, the intent of that distinction is actually to differentiate things you explicitly decided to keep (bookmarks, passwords, site settings) versus ones we just accumulated by virtue of you using your browser (history, cookies, cache). Web cache and active logins both feel like "History" by that definition (timespan wording bug aside :). Does that make sense? I think blocking the checkboxes prevents the accidental deletion we're worried about here, and that long term, time-based eviction would be even better. I'm worried that moving these checkboxes to the "Data" section will be a thing we do because of our own implementation limitations, not because the resultant categories represent meaningful distinctions for our users.

(In reply to comment #5) > I don't think I like moving them to the bottom category as much. While it's > true that the History category is controlled by the timespan combo where the > Data category isn't, the intent of that distinction is actually to > differentiate things you explicitly decided to keep (bookmarks, passwords, site > settings) versus ones we just accumulated by virtue of you using your browser > (history, cookies, cache). Web cache and active logins both feel like > "History" by that definition (timespan wording bug aside :). > > Does that make sense? I think blocking the checkboxes prevents the accidental > deletion we're worried about here, and that long term, time-based eviction > would be even better. I'm worried that moving these checkboxes to the "Data" > section will be a thing we do because of our own implementation limitations, > not because the resultant categories represent meaningful distinctions for our > users. It makes sense yes, and I'm sure there is no ideal here. For me enabling/disabling the checkboxes will confuse users I think, but maybe the way to go anyway.

Adding a 1-day SWAG based on the idea of disabling the checkboxes because I think that will prevent mistakes from happening, even if it's suboptimal. Optimal would be to have these things be time-sensitive (especially cache!) so that they could be expunged properly. I can file a follow-up for that support as well, when adding it won't change IDLs at the end of a release.

Switching back to blocking nomination, as some good counter arguments are: - user needs to be looking at filesys to notice that we've expunged all cache - we expunge cache all the time, user doesn't normally have control, so dataloss while technically correct, isn't really as much a concern

>so dataloss while technically correct, isn't really as much a concern I would add that in privacy interfaces, data preservation is sort of the new dataloss. If the user's goal is to clear data, clearing more than intended, while not ideal, is more inline with their overall goal than failing to clear the cache. >disabling the checkboxes In the event that the backend remains suboptimal, I'm not sure we really want to expose this limitation to the user. If they see too much cache being deleted, perhaps they need to stop micromanaging the internal operations of their browser :)

Counter arguments win the day. We should fix this but it doesn't block.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information