User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1 Build ID: 20120614114901 Steps to reproduce: Selected tools->Clear Recent History->Last Hour Actual results: In addition to clearing recent history, it removed all zooming (e.g. from when I pressed ctrl and + buttons) on all sites even though I had pressed ctl+ a week earlier. Expected results: The zooming settings should have remained.

This still occurs in FF20.

FYI: https://hg.mozilla.org/mozilla-central/annotate/7a2edc5171e6/browser/base/content/sanitize.js#l104 siteSettings: { not include if (this.range) {

(In reply to YF (Yang) from comment #3) > FYI: > https://hg.mozilla.org/mozilla-central/annotate/7a2edc5171e6/browser/base/ > content/sanitize.js#l104 > siteSettings: { not include if (this.range) { I see your comment, but I don't see that code anywhere. I just see it defaulting to still clearing everything.

To donrhummy: That was my reference to johnath (the code's developer), but he does not seem interested.

I suddenly understood, zoom preferences's structure may not contain a timestamp, so impossible to clear specified time range, have to clear all. https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIContentPrefService2 so, to enhancement?

Note that this affects both the Permission Manager, Content Pref Service, & Password Manager Exceptions (which should probably switch to using the Permission Manager). We could add a new modification time column to the two stored and set its value to the current time when a permission or content pref changes. When sanitize.js is used just remove permissions that have a modification time in the time window specified. I realize this isn't perfect because it won't revert the permission to a previous non-default value from before the time period chosen but I think it's "good enough" and better than the current situation of deleting all permissions/preferences.

Given this was opened by a user reporting a real bug, it doesn't seem correct to have it morphed into a "breakdown" and thus marked as fixed when the breakdown is complete rather than the issue being addressed. I opened bug 1058430 to be the actual breakdown, and I'll mark the relevant sub-bugs as blocking this one. Marco, please update the current iteration spreadsheet accordingly.

Thanks for the update Mark. I've made the update to reflect your changes. (In reply to Mark Hammond [:markh] from comment #8) > Given this was opened by a user reporting a real bug, it doesn't seem > correct to have it morphed into a "breakdown" and thus marked as fixed when > the breakdown is complete rather than the issue being addressed. > > I opened bug 1058430 to be the actual breakdown, and I'll mark the relevant > sub-bugs as blocking this one. Marco, please update the current iteration > spreadsheet accordingly.

Per email discussion, seems like this should be a meta bug.

Thanks for catching that Gijs. (In reply to :Gijs Kruitbosch from comment #10) > Per email discussion, seems like this should be a meta bug.

All the dependencies are now fixed! The Site Settings option respects the time period.