Closed
Bug 867110
Opened 12 years ago
Closed 10 years ago
"clear history" should allow the option to delete only the oldest data
Categories
(Firefox :: Bookmarks & History, enhancement)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: t8av, Unassigned)
References
Details
Attachments
(3 files, 1 obsolete file)
69.57 KB,
image/png
|
Details | |
7.65 KB,
patch
|
Details | Diff | Splinter Review | |
30.23 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949
Steps to reproduce:
Due to browser slowness, I decided to delete the oldest browser data ("Cache" + "Browsing and download history").
Actual results:
I could not find such an option in Firefox.
I could delete only the recent browsing history. That is something that I do not want to do since I am in the middle of checking of some links and I need to know in which websites I already visited (Firefox colors the already-visited websites). However, I do not mind to delete the very old website browsing history.
Expected results:
Firefox should allow selective deletion of the oldest data such as:
"Delete all data of previous years/months/etc".
"Delete all data before specific data _______".
Comment 1•12 years ago
|
||
Related: bug 633782.
Component: Untriaged → Private Browsing
OS: Windows 7 → All
Updated•12 years ago
|
Component: Private Browsing → General
Updated•12 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•12 years ago
|
Component: General → Bookmarks & History
I'd be quite keen to take this on.
One thing that isn't obvious is how to deal with cookies.
The naive way of doing it, and essentially how they are done now, is to check the creation date against the timespan being cleared. That conforms perfectly to the stated action of "clearing old data", and if someone did have a privacy or other reason for wanting every record from before a certain date gone, this would do that.
However,as cookies are intended to be persistent, they may have been created before the cut off but still be in regular use. If it can be assumed that the primary use case of clearing old data is minimizing disruption to current work caused by basic maintenance, clearing out cookies which have been used recently and are likely to be used again violates this principle.
My own inclination is to cater first to the maintenance use case, but I'm open to suggestions
Normal history items and downloads should not have this problem as each visit is unique; the dilemma is averted for other persistent storage such as the cache as they doesn't support partial clearing at all.
Attachment #8468558 -
Flags: ui-review?
Attachment #8468558 -
Flags: review?(gavin.sharp)
If the approach is deemed valid and more choice is desirable for keeping the last month or three of data, appropriate menu entries would be inserted below "Before Last Week".
Similarly, may suggest change of whole dialogue/menu item from Clear Recent History to Clear History if there's an explicit option for keeping recent history.
Attachment #8468561 -
Flags: ui-review?(ux-review)
Comment on attachment 8468558 [details] [diff] [review]
A patch that allows for clearing history older than a week; easily extensible to other time options.
># HG changeset patch
># Parent b50bb656674eeff737b78aecd610df281aa93afc
># User Josiah Kane <josiah.kane@gmail.com>
>Bug 867110 - Add option in clear recent history dialogue to delete only data older than one week. This includes cookies only if they were last used (set or sent) more than 1 week ago. r=
>
>
>
>diff --git a/browser/base/content/sanitize.js b/browser/base/content/sanitize.js
>--- a/browser/base/content/sanitize.js
>+++ b/browser/base/content/sanitize.js
>@@ -135,24 +135,25 @@ Sanitizer.prototype = {
> },
>
> cookies: {
> clear: function ()
> {
> var cookieMgr = Components.classes["@mozilla.org/cookiemanager;1"]
> .getService(Ci.nsICookieManager);
> if (this.range) {
>- // Iterate through the cookies and delete any created after our cutoff.
>+ // Iterate through the cookies and delete any inside the cuttoff times.
> var cookiesEnum = cookieMgr.enumerator;
> while (cookiesEnum.hasMoreElements()) {
> var cookie = cookiesEnum.getNext().QueryInterface(Ci.nsICookie2);
>
>- if (cookie.creationTime > this.range[0])
>- // This cookie was created after our cutoff, clear it
>+ if (cookie.creationTime > this.range[0] && cookie.lastAccessed < this.range[1]) {
>+ // This cookie was created since the start of our range and last used before the end, clear it.
> cookieMgr.remove(cookie.host, cookie.name, cookie.path, false);
>+ }
> }
> }
> else {
> // Remove everything
> cookieMgr.removeAll();
> }
>
> // Clear plugin data.
>@@ -404,53 +405,75 @@ Sanitizer.prototype = {
>
> // "Static" members
> Sanitizer.prefDomain = "privacy.sanitize.";
> Sanitizer.prefShutdown = "sanitizeOnShutdown";
> Sanitizer.prefDidShutdown = "didShutdownSanitize";
>
> // Time span constants corresponding to values of the privacy.sanitize.timeSpan
> // pref. Used to determine how much history to clear, for various items
>-Sanitizer.TIMESPAN_EVERYTHING = 0;
>-Sanitizer.TIMESPAN_HOUR = 1;
>-Sanitizer.TIMESPAN_2HOURS = 2;
>-Sanitizer.TIMESPAN_4HOURS = 3;
>-Sanitizer.TIMESPAN_TODAY = 4;
>+Sanitizer.TIMESPAN_EVERYTHING = 0;
>+Sanitizer.TIMESPAN_HOUR = 1;
>+Sanitizer.TIMESPAN_2HOURS = 2;
>+Sanitizer.TIMESPAN_4HOURS = 3;
>+Sanitizer.TIMESPAN_TODAY = 4;
>+Sanitizer.TIMESPAN_BEFORE_LAST_WEEK = 5;
>
> // Return a 2 element array representing the start and end times,
> // in the uSec-since-epoch format that PRTime likes. If we should
> // clear everything, return null. Use ts if it is defined; otherwise
> // use the timeSpan pref.
> Sanitizer.getClearRange = function (ts) {
> if (ts === undefined)
> ts = Sanitizer.prefs.getIntPref("timeSpan");
> if (ts === Sanitizer.TIMESPAN_EVERYTHING)
> return null;
>-
>- // PRTime is microseconds while JS time is milliseconds
>- var endDate = Date.now() * 1000;
>- switch (ts) {
>- case Sanitizer.TIMESPAN_HOUR :
>- var startDate = endDate - 3600000000; // 1*60*60*1000000
>- break;
>- case Sanitizer.TIMESPAN_2HOURS :
>- startDate = endDate - 7200000000; // 2*60*60*1000000
>- break;
>- case Sanitizer.TIMESPAN_4HOURS :
>- startDate = endDate - 14400000000; // 4*60*60*1000000
>- break;
>- case Sanitizer.TIMESPAN_TODAY :
>- var d = new Date(); // Start with today
>- d.setHours(0); // zero us back to midnight...
>- d.setMinutes(0);
>- d.setSeconds(0);
>- startDate = d.valueOf() * 1000; // convert to epoch usec
>- break;
>- default:
>- throw "Invalid time span for clear private data: " + ts;
>+
>+ Sanitizer.recentTimeSpans = Set([Sanitizer.TIMESPAN_HOUR, Sanitizer.TIMESPAN_2HOURS, Sanitizer.TIMESPAN_4HOURS, Sanitizer.TIMESPAN_TODAY]);
>+ Sanitizer.earlierTimeSpans = Set([Sanitizer.TIMESPAN_BEFORE_LAST_WEEK]);
>+ if (Sanitizer.recentTimeSpans.has(ts)) {
>+ // if we're clearing data from some start time until now
>+ // PRTime is microseconds while JS time is milliseconds
>+ var endDate = Date.now() * 1000;
>+ switch (ts) {
>+ case Sanitizer.TIMESPAN_HOUR :
>+ var startDate = endDate - 3600000000; // 1*60*60*1000000
>+ break;
>+ case Sanitizer.TIMESPAN_2HOURS :
>+ startDate = endDate - 7200000000; // 2*60*60*1000000
>+ break;
>+ case Sanitizer.TIMESPAN_4HOURS :
>+ startDate = endDate - 14400000000; // 4*60*60*1000000
>+ break;
>+ case Sanitizer.TIMESPAN_TODAY :
>+ var d = new Date(); // Start with today
>+ d.setHours(0); // zero us back to midnight...
>+ d.setMinutes(0);
>+ d.setSeconds(0);
>+ startDate = d.valueOf() * 1000; // convert to epoch usec
>+ break;
>+ default:
>+ // can't happen, ts already checked
>+ throw "Invalid recent time span for clear private data: " + ts;
>+ }
>+ } else if (Sanitizer.earlierTimeSpans.has(ts)) {
>+ // if we're clearing data from antiquity until some end time e
>+ // start from the epoch.
>+ var startDate = 0;
>+ switch (ts) {
>+ case Sanitizer.TIMESPAN_BEFORE_LAST_WEEK :
>+ var e = Date.now() * 1000; // start with now, in PRTime microseconds since epoch
>+ endDate = e - 604800000000; // and rewind it 1 week : 7*24*60*60*1000000
>+ break;
>+ default:
>+ // can't happen, ts already checked
>+ throw "Invalid early time span for clear private data: " + ts;
>+ }
>+ } else {
>+ throw "Invalid time span for clear private data: " + ts;
> }
> return [startDate, endDate];
> };
>
> Sanitizer._prefs = null;
> Sanitizer.__defineGetter__("prefs", function()
> {
> return Sanitizer._prefs ? Sanitizer._prefs
>diff --git a/browser/base/content/sanitize.xul b/browser/base/content/sanitize.xul
>--- a/browser/base/content/sanitize.xul
>+++ b/browser/base/content/sanitize.xul
>@@ -80,16 +80,18 @@
> #ifdef CRH_DIALOG_TREE_VIEW
> <menuitem label="" value="-1" id="sanitizeDurationCustom"/>
> #endif
> <menuitem label="&clearTimeDuration.lastHour;" value="1"/>
> <menuitem label="&clearTimeDuration.last2Hours;" value="2"/>
> <menuitem label="&clearTimeDuration.last4Hours;" value="3"/>
> <menuitem label="&clearTimeDuration.today;" value="4"/>
> <menuseparator/>
>+ <menuitem label="&clearTimeDuration.before1Week;" value="5"/>
>+ <menuseparator/>
> <menuitem label="&clearTimeDuration.everything;" value="0"/>
> </menupopup>
> </menulist>
> <label id="sanitizeDurationSuffixLabel"
> value="&clearTimeDuration.suffix;"/>
> </hbox>
>
> <separator class="thin"/>
>diff --git a/browser/locales/en-US/chrome/browser/sanitize.dtd b/browser/locales/en-US/chrome/browser/sanitize.dtd
>--- a/browser/locales/en-US/chrome/browser/sanitize.dtd
>+++ b/browser/locales/en-US/chrome/browser/sanitize.dtd
>@@ -11,16 +11,17 @@
> <!-- LOCALIZATION NOTE (clearTimeDuration.*): "Time range to clear" dropdown.
> See UI mockup at bug 480169 -->
> <!ENTITY clearTimeDuration.label "Time range to clear: ">
> <!ENTITY clearTimeDuration.accesskey "T">
> <!ENTITY clearTimeDuration.lastHour "Last Hour">
> <!ENTITY clearTimeDuration.last2Hours "Last Two Hours">
> <!ENTITY clearTimeDuration.last4Hours "Last Four Hours">
> <!ENTITY clearTimeDuration.today "Today">
>+<!ENTITY clearTimeDuration.before1Week "Before Last Week">
> <!ENTITY clearTimeDuration.everything "Everything">
> <!-- Localization note (clearTimeDuration.suffix) - trailing entity for languages
> that require it. -->
> <!ENTITY clearTimeDuration.suffix "">
> <!ENTITY clearTimeDuration.dateColumn "Visit Date">
> <!ENTITY clearTimeDuration.nameColumn "Name">
>
> <!-- LOCALIZATION NOTE (detailsProgressiveDisclosure.*): Labels and accesskeys
Previous patch, sans the scoping error on the two sets used for pointing getClearRange to the appropriate switch.
Attachment #8468558 -
Attachment is obsolete: true
Attachment #8468558 -
Flags: ui-review?
Attachment #8468558 -
Flags: review?(gavin.sharp)
Attachment #8469290 -
Flags: review?(gavin.sharp)
Attachment #8469492 -
Flags: review?(gavin.sharp)
Comment 9•10 years ago
|
||
Thanks so much for the patches, Josiah!
This is an interesting idea, but I see a few issues, one small and one large:
- the feature is called "Clear Recent History" - we'd probably want to rename it if we're turning it into a way to clear history more generally
- it's not clear to me that this particular use case is common enough to be worth implementing - it shouldn't be the case that clearing out old history fixes "browser slowness", in general, so it seems odd that we'd encourage it by offering the feature. Potential performance benefits aside, clearing "most history" but not "all history" just doesn't seem like that compelling of a feature to merit the additional complexity to this UI.
What do you think? We can also loop in some product design experts to get their take, but I'm inclined to mark this WONTFIX, and perhaps suggest that it get packaged up into an add-on instead if some people consider that useful.
Comment 10•10 years ago
|
||
In terms of the use case, I may be optimistic but I honestly think it would subsume most of the use from the clear Everything option, plus a proportion of people who do the same with CCleaner and the like.
My thinking essentially is that the current partial clears are all based on the assumption that the information in the history is bad--that is, you started browsing for an hour or so on sites you'd normally want to be in Private, but forgot to hit the appropriate button.
The use case for clear everything option is the opposite: there's nothing wrong with this information, its sat there for months or years and no-one's noticed, but now it's basically gone stale. History does go stale; I don't think it's much of a stretch to suppose that almost all of the value in the history for a typical user is in the last month or so, and it starts to drop off pretty quickly within days or even hours. I'd also take an axiom that a lot of people are using their browsers constantly, so it's hard to find natural breaks for a bit of spring cleaning.
Now, the use case of a clear almost everything button absorbs the use case of the clear Everything button -- cleaning out the stale crud for whatever reasons people have for that -- without the associated cost of throwing away such of the history as might be valuable information.
I still wouldn't suggest ditching the clear everything button, but only really for the psychological or almost artistic notion that it completes the set. If you think that that is the only reason for having said button even in the status quo, then I'd agree that the patch doesn't merit adding.
I agree about the UI thing, and mentioned it and a few little related things in the comment to the photo. (comment 5)
Comment 11•10 years ago
|
||
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #9)
> This is an interesting idea, but I see a few issues, one small and one large:
> - the feature is called "Clear Recent History" - we'd probably want to
> rename it if we're turning it into a way to clear history more generally
Honestly I think we should more generally redesign the way we present history to the user. We need something better to manage it, either search or clean. Let's think about about:history and about:me for example. An history dedicated page might allow for more fine grained search and removal options.
Also moving from a dialog to an in-content page would give us more space to build a better remove history UI.
> - it's not clear to me that this particular use case is common enough to be
> worth implementing - it shouldn't be the case that clearing out old history
> fixes "browser slowness", in general
Indeed if we'd figure that's the case we should rather tweak expiration to be more aggressive. We are already purging old history automatically, should not be a user task.
Comment 12•10 years ago
|
||
(In reply to Josiah from comment #10)
> In terms of the use case, I may be optimistic but I honestly think it would
> subsume most of the use from the clear Everything option, plus a proportion
> of people who do the same with CCleaner and the like.
Seems unlikely to me - I think some people do want to "clear all history" relatively often enough, and that most of those people would not be satisfied with only having a "clear really old history" option.
> My thinking essentially is that the current partial clears are all based on
> the assumption that the information in the history is bad--that is, you
> started browsing for an hour or so on sites you'd normally want to be in
> Private, but forgot to hit the appropriate button.
Yes, this is pretty much the reasoning for adding this feature originally.
> If you think that that is the only reason for having said button even
> in the status quo, then I'd agree that the patch doesn't merit adding.
I think there's value in "clear all history" for reasons unrelated to "removing old cruft", so I think the status quo is OK.
Thanks for digging in to this, Josiah, but this is sounding like a WONTFIX, so I'm going to mark it as such.
If you're interesting in contributing to other areas of Firefox, https://twitter.com/StartMozilla is a great way to find suggestions, and I'd be happy to make other suggestions myself - let me know.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Attachment #8469492 -
Flags: review?(gavin.sharp)
Updated•10 years ago
|
Attachment #8469290 -
Flags: review?(gavin.sharp)
Updated•10 years ago
|
Attachment #8468561 -
Flags: ui-review?(ux-review)
You need to log in
before you can comment on or make changes to this bug.
Description
•