Closed Bug 660646 Opened 13 years ago Closed 8 years ago

Restore Capability -- With User Interface -- to Expire History Entries by Age

Categories

(Toolkit :: Places, enhancement)

Product:
Toolkit
Component:
Places
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: david, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 SeaMonkey/2.1
Build Identifier: 

The capability to expire history entries has been removed.  Please restore it.  

When I view a page containing links, I want the color-code for a "visited" link after some number of days to change to the color-code for a "not visited" link.  In the past, I usually set this to 30 days, without regard for privacy, performance, the size of my history file, or the list in my address bar.  I  increased the number of days if I was going to be away from my computer for an extended vacation, decreasing it after resuming Web surfing.  

Manually deleting a month at a time by deleting a folder within the History window -- deleting April near the end of May -- caused me to lose ALL history.  See bug #660543.  

Reproducible: Always




From the Description in bug #643254:
time is an intuitive and sensible way to think of expiration, whereas number of pages is a meaningless criterion to a human being

> you don't need anymore to tell us how much days of history
> your computer can handle. [from <http://blog.bonardo.net/2010/01/20/places-got-async-expiration.]

this completely misses the point, it's not about the computer, but the user's subjective determination of when a visit is no longer worth remembering

I presume you are still expiring based on age, once the page threshold is reached, so all that you've done is make the pref suit the code and not the user
(In reply to comment #0)
> When I view a page containing links, I want the color-code for a "visited"
> link after some number of days to change to the color-code for a "not
> visited" link. 

please explain why, real use-cases are more useful than "I want to do this", we can't implement features based on single user habits.

> I  increased the number of days if I was going to be away from
> my computer for an extended vacation, decreasing it after resuming Web
> surfing.  

Don't you think requiring all users to have to manually do this is unfortunate and a drawback of the approach you suggest?

> Manually deleting a month at a time by deleting a folder within the History
> window -- deleting April near the end of May -- caused me to lose ALL
> history.  See bug #660543.  

This has nothing to do with this report, it has its own bug and it even may be working as expected.

To me looks like you are filing a slightly different enh request (fine), but bringing back what was already discusses in bug 643254 as a side note (bad), please don't, it's not useful to anyone to have a duplicate of a wontfix bug.
> please explain why, real use-cases are more useful than 
> "I want to do this", we can't implement features based on single 
> user habits.  

I read amateur fiction on-line, most of which is serial.  That is, a story is spread over many chapters placed on the Web at intervals from week to many months.  When I visit a story's Web site (which I have bookmarked) and see that prior chapters have been visited but the latest chapter has not, I go directly to that chapter.  Sometimes, however, I see that the prior chapter has not yet been visited but chapters before then have been; I then catch up with the missed chapter and then read the latest.  On the other hand, if I see that none of the chapters have been visited, that tells me it has been at least a month since I read the last prior chapter; I go to that prior chapter and reread the end of it to refresh my memory of the story.  

This, I think, is an easily understood case.  However, I have several other cases involving visiting blogs, newspaper sites, forums, etc.  I do sometimes want to reread something that I read before but not recently.  I should think other users want to experience the Web in a similar manner.  

As for bug #660543, I tried to do manually what this RFE would provide in a cleaner implementation.
In comment #1, I read "we can't implement features based on single user habits."  

The user comments in the blog at <http://blog.bonardo.net/2010/01/20/places-got-async-expiration> and at bug #643254 should indicate that this RFE would have the support of more than a single user.  

While the developers might be enamored of the current implementation, users nonetheless want to be able to expire history entries by age.  Furthermore, we would expect that revisiting a Web page would update the history entry to the latest visit without creating a new entry, which would mean deleting an old entry would not cause the entry for a more recent visit to that same page to be deleted.
I agree with the above.  I used to have the history expire at four days; since this was a feature of prior releases, it would be nice if it were reinstated.
The extension cited in comment #5 cannot be installed in SeaMonkey.  Also, the "Warning" on the page at the extension's Web page ignores the number of comments -- both in newsgroups and in the blog cited in my original Description below -- that users indeed want this capability.  

In any case, an extension can only be considered a temporary work-around and not a solution to this RFE.
You can expire manually without an extension:

https://bugzilla.mozilla.org/show_bug.cgi?id=643254#c39

Here's an error console snippet to manually expire.  It prompts for the number of days to keep.  Today counts as one day, regardless of time of invocation. 

Components.classes['@mozilla.org/browser/nav-history-service;1'].getService(Components.interfaces.nsIBrowserHistory).removeVisitsByTimeframe(0, (new Date().setHours(0, 0, 0, 0) - (parseInt(prompt('Days of history to keep', 30)) - 1) * 24 * 60 * 60 * 1000) * 1000 - 1)
This RFE is for end-users.  Using an Error Console command is clearly not user-oriented.  However, I will indeed try this after saving my profiles.
The extension perfectly covers the needs of those users who complained, reporting one valid and rare use-case, so far (your use-case in this bug).
If I'd want to ignore users, I'd not put efforts and time in making an add-on. If the number of users requesting the feature would be that high as you think, someone would have already put together an add-on like this one, that is just a few rows of code (may be smaller than it is, next version will be), mostly doing what that error console snippet does. Nobody did.
I'll look into Seamonkey compatibility for sure, when I have the time, thanks for feedback on that.
> If the number of users requesting the feature would be that high as you think, 
> someone would have already put together an add-on like this one,
> Nobody did.

That one has an easy answer, users are not programmers and they don't care. If an application stops being useful or convenient they will switch to another one that is. They are not going to submit bug reports, that takes a lot of time specially if they will have to argue with stubborn people. Probably the only indication of what happened would be some posts on random forums and blogs of people telling their stories of how they upgraded to Chrome from Mozilla and never looked back.

In my case I'll still using version 2.0.14 and eventually I might start using Internet Explorer where the option to keep history by days is still there.

Unfortunately this situation only proves that FOSS only works in a world where everybody is a developer or users will have to suffer the tyranny of the developers still interested in a project. While I don't regret making a donation to the Mozilla Foundation for the good job done in the past, certainly I will not be interested to make another one.
(In reply to paladinsama from comment #10)
> That one has an easy answer, users are not programmers and they don't care.

You miss the point of request and offer, most of the existing add-ons are done by developers based on users requests.  Just look at how many add-ons exist to restore 3.x functionality, because lots of users wanted those, developers try to cope with users requests, not to make some exotic add-on that they only need.
If you want more input, we also have http://input.mozilla.com.
Btw, this is not the right place to discuss this, if you want to continue the discussion I have to invite you to mozilla.dev.apps.firefox.
And you missed the point that I don't care. I don't need to start begging for developers to code add-ons and then beg them again when a new version number breaks their add-on, when there is a previous version that works better (and other products that work well too). I feel sad that I stopped caring about new SeaMonkey versions.
Btw, this is about Seamonkey not Firefox.
Re comment #12:  Actually, this is a Toolkit issue affecting both SeaMonkey and Firefox.  From comments regarding Firefox, however, I suspect the necessary user interface might only be implemented in SeaMonkey.
I sure do agree this is important functionality that should be a basic included feature and not an add-in.

We like(ed) Seamonkey because it was useful practical and user oriented. I can't imagine anyone "wanting" an unlimited history clogging up their computer, many probably haven't realized this is happening to them.

I would also or maybe better yet like to see a setting that limits the history to a certain number of entries, based on frequency of use.  So, a site I visit every day would never drop off, and the least-used one-time only sites would drop off when that number is reached.
Just to say I am one of those wanting to clog my comp with unlimited history - so I agree with comment 14 above that : this is important functionality that should be a basic included feature and not an add-in.
Cause - in my (nut)case - I had this setting to 9999 days and never loosing a page - especially the ones I visited once after a lot of googling.

So yes - bring it back (in FF)

:)
(In reply to Palmer Eldritch from comment #15)
> Cause - in my (nut)case - I had this setting to 9999 days and never loosing
> a page - especially the ones I visited once after a lot of googling.

you can still do this with the new prefs, you have not lost any functionality, nor the possibility to kill your own performances :)

And history is not unlimited, it is expired when needed for performance reasons, that on some system may mean months, on some system may be years.
(In reply to Marco Bonardo [:mak] from comment #16)
> (In reply to Palmer Eldritch from comment #15)
> > Cause - in my (nut)case - I had this setting to 9999 days and never loosing
> > a page - especially the ones I visited once after a lot of googling.
> 
> you can still do this with the new prefs, you have not lost any
> functionality, nor the possibility to kill your own performances :)
> 
How ?
> And history is not unlimited, it is expired when needed for performance
> reasons, that on some system may mean months, on some system may be years.
You just said I can make it "unlimited" (9999 days) - independently of my machine - as I use it on many machines
Where would we (average users) find out about the "new prefs"??

I would like to decide for myself when history entries are deleted.
Re comment #16:  What are the "new prefs", and where are they documented FOR USERS?  

In any case, this RFE is for a user interface, which would be beyond setting preferences via either about:config or user.js.
The script offered in comment #7 has been incorporated into a PrefBar button available at <http://prefbar.tuxfamily.org/buttons.html#expirehistory>.  The PrefBar extension itself can be found at <https://addons.mozilla.org/en-US/seamonkey/addon/prefbar/> for SeaMonkey or at <https://addons.mozilla.org/en-US/firefox/addon/prefbar/> for Firefox.
(In reply to Marco Bonardo [:mak] from comment #9)
> I'll look into Seamonkey compatibility for sure, when I have the time,
> thanks for feedback on that.

Have you made any progress concerning this?
thank you and kind regards
(In reply to David E. Ross from comment #19)
> Re comment #16:  What are the "new prefs", and where are they documented FOR
> USERS?  

The preference names are listed in the blog post that you linked to in the description of this bug report:

places.history.expiration.interval_seconds is number of seconds between each expiration step, while places.history.expiration.max_pages is maximum number of pages that we will retain before expiring.

The official knowledgebase at support.mozilla.org seems to make a point to avoid mention of about:config whenever possible. It is documented in the page for developers, however:
https://developer.mozilla.org/En/Places_Expiration
Re comment #23:  

The preference variable places.history.expiration.interval_seconds determines how often the history-purging process runs, not how old a history entry should be before it is purged.  

This bug report requests a restoration of the capability for a user to specify the automatic purging of history entries that are beyond a certain age (generally specified in days not seconds, my preferred 30 days = 2,592,000 seconds).  

So far, 117 users have downloaded the additional PrefBar button (based on the script in comment #7) that allows them to delete history by days of age.  The button is at <http://prefbar.tuxfamily.org/buttons.html>, not on PrefBar's addons.mozilla.org site.  Any extension should be considered to be not more than a temporary workaround for a problem.  In this case, the workaround involves the user getting an add-on (the button) to an add-on (PrefBar) and then importing the button into PrefBar -- quite an obscure workaround that nonetheless attracted 117 users.  Thus, I and the other eight users who voted for this bug report are far from alone in requesting the RFE.
Today's XKCD comic http://xkcd.com/1051/ explains perfectly clearly why auto deleting history older than X days is a very useful feature.
An analogy as to why this is a sensible feature:

When you clear out stuff in real life (a pile of magazines, receipts, bank statements, your sock drawer, the fridge, the recordings on your PVR, the garage...) you throw away the old stuff that you no longer need *but keep the new stuff*. You don't either only throw away the recent stuff or throw away absolutely everything at once!

Browsing history should be the same. I may want to refer back to a site I accessed last week. I don't care about a site I haven't accessed for 6 months...
there should not only be a max_days setting, but also a min_days setting, to ensure the new places system does not decide to delete a pageview too early.
Ditto. I finally switched to v2.10.1 and was disappointed by this. I want to keep a month of history by ages! I surf a lot and can't remember the ones I already been  to. :(
I'm also not very fond of this change.  Please consider giving us back this option.
OS: Windows XP → All
I'm sorry, we are not planning to reintroduce this.
If you need a similar functionality I made an add-on for it https://addons.mozilla.org/en-US/firefox/addon/expire-history-by-days
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Please consider these points:

1. Firefox collects more history than other major browsers which conflicts with its pro-privacy marketing.

  * Chrome:                 90 days (longer archiving removed by Issue 359377). 
  * Internet Explorer 11:   20 days (adjustable)
  * Microsoft Edge:         ? days (feature incomplete)
  * Safari 8:               7 days (one day, one week, two weeks, one month, one year or manual)
  * Firefox:                ∞ days (size limit only for performance reasons)

2. There is no easy way to expire pages in history by age, attempting to manually remove older pages is not only time consuming and cumbersome but also removes recent pages (Bug 660543). 

3. The history clearing options available are all or nothing, having to wipe history completely to remove older pages sacrifices the benefits of having a history.

4. Asynchronous clearing is less reliable for privacy purposes but should not rule out expiration which is still very useful, a minimum time limit is still possible and the setting can be worded to reflect that:
> "Remember visited pages for at least x days."

5. Neither Internet Explorer or Safari include their history time limit setting in their privacy sections, indicating it is not strictly a privacy feature.

6. History quickly loses relevance in the long term but continues to affect location bar searches and visited links, history expiration gets rid of this unwanted noise without user intervention.

7. A time limit for history is more natural and predictable than a size limit (form data uses a 180 day limit) and an absolute size limit can still be used for performance reasons. To communicate this the setting can be worded: 
> "Try to remember visited pages for at least x days."

8. The addon is nice but doesn't provide the same level of support, consideration or adoption as an official built-in setting and has an uncertain future with XPCOM being deprecated.
(In reply to Kestrel from comment #31)
> 1. Firefox collects more history than other major browsers which conflicts
> with its pro-privacy marketing

There is no direct relation between length of history and privacy, you may have a 7 days history with very embarassing content, or 10 years of history with unicorn related websites...
It's better to concentrate on shipping nice privacy tools (private browsing, tracking protection) than trying to limit damage.
Also consider the most common requests we get are to enlarge history, not shrink it...

> 2. There is no easy way to expire pages in history by age, attempting to
> manually remove older pages is not only time consuming and cumbersome but
> also removes recent pages (Bug 660543). 

The history view can be confusing, and make it look like it's wiping whole history. it's removing selected URIs instead. What I suggest is search through history for content and THEN remove it.
Plus there's an add-on for users needing the old behavior.

> 5. Neither Internet Explorer or Safari include their history time limit
> setting in their privacy sections, indicating it is not strictly a privacy
> feature.

Indeed history length is not a privacy feature, it's mostly an internal implementation detail.

> 6. History quickly loses relevance in the long term but continues to affect
> location bar searches and visited links, history expiration gets rid of this
> unwanted noise without user intervention.

yes, we do history expiration exactly for that reason, otherwise we'd keep infinite history. We do not.

> 7. A time limit for history is more natural and predictable than a size
> limit (form data uses a 180 day limit) and an absolute size limit can still
> be used for performance reasons. To communicate this the setting can be
> worded: 
> > "Try to remember visited pages for at least x days."

It doesn't scale well to user habits, in 180 days a user could collect 100 pages, another one 500k, and the system should be supposed to perform well in both cases... Plus for the user with few pages history would expire too fast and he'd had to search again stuff.

> 8. The addon is nice but doesn't provide the same level of support,
> consideration or adoption as an official built-in setting and has an
> uncertain future with XPCOM being deprecated.

Well, it's an add-on made by a Mozilla developer and uses a single API call... I'm sure it will survive.
> There is no direct relation between length of history and privacy, you may have a 7 days history with very embarassing content, or 10 years of history with unicorn related websites...

Privacy is not about "having something to hide", but about wanting privacy. Nobody should know about my unicorns. I Do not only need privacy, when there is something embaressing, i want privacy by default.

So the length IS a privacy feature, as either someone can see your 10 years of unicorns, or only the unicorns of the last 7 days.

Indeed it's even the other way round: When i come to some site, which looks bad in the (autocomplete) history, i probably will hit "delete browing history of the last 10 minutes" from the history menu. But when everything looks fine, i collect my browing habits of the last 10 years. Open for everyone using the browser or any (maybe newly installed) addon.
An extension can be considered only as a temporary work-around for an actual fix.  Changes in the base code -- in this case, Toolkit/Places -- too easily result in breaking extensions.  Furthermore, the expire-history-by-days extension does not work with either SeaMonkey or Thunderbird, both of which save history in places.sqlite.  

The expire-history-by-days extension might be considered more acceptable (but nonetheless long-term temporary) with the following conditions:  

1.  The Mozilla organization (not merely the author) committed to maintaining the extension.  

2.  The extension is modified for compatibility with SeaMonkey, Thunderbird, and any other Mozilla-based application that uses Toolkit/Places.  

The 5,265 users who have downloaded the extension should indicate the end-user interest in having this bug fixed.  In the meantime, lacking the two conditions stated above, this bug report should remain open.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
As I said, no plan to do this, the reasons it was removed are still valid.
Please do not abuse editbugs power or I'll have to report that to admins.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
The right place for advocacy is the mailing list (https://wiki.mozilla.org/Firefox/firefox-dev). This bug is not going to get fixed just by reopening it or incessantly commenting. I'm restricting comments; please take further ones to the mailing list.
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.