SM 2.4 browser history expiry duration

[webmoebius]

Can someone advise me what parameters if any in the about:config page of the SM 2.2 to 2.4 browser that I can set a browser history expiry duration as with older versions of SM? Previously I would set it to 30 to 45 days. However, with the current version of SM, this parameter appears to have been removed from preferences settings and I noticed that my browser history goes back to more than 6 months ago. I found two parameters:

browser.history_expire_days_min
browser.history_expire_sites

and have already set the first parameter to 30 days but not sure why history is kept up to beyond 6 months.

[ElTxolo]

See:
Is there a history setting anymore?

For some of the reasoning for the change and some options for dealing with it:

http://blog.bonardo.net/2010/01/20/plac ... expiration
http://blog.bonardo.net/2011/08/05/a-co ... aintenance

[webmoebius]

Thanks for the links. Based on the various articles and explanations there, it seems that the system is storing as much history as possible by default. However, this isn't what I really want SM to do so I have added a new parameter of places.history.expiration.max_pages and set its integer value accordingly to my preference to see how the history archive logic behaves.

However, I found something amiss with the history database as it is right now in SM 2.4 - I have a history group called OLDER THAN 6 MONTHS, and when I expand this group to look at the history, there are clearly entries in this group that are absolutely LESS than 6 months old, some even just a month or two ago, so it would appear that the history sorting is incorrect or buggy somehow. Has anyone else noticed this same problem?

[ElTxolo]

You're Welcome!

[therube]

Bug 672429 - Deleting Browser History (Ctrl+H) is Fubar'd, Deleting Far More then Wanted

[webmoebius]

Bug 672429 - Deleting Browser History (Ctrl+H) is Fubar'd, Deleting Far More then Wanted

I wish they would have stuck with the simple expiry by date as it was before, the "sophisticated" reasons for dropping that notwithstanding.

[ElTxolo]

Bug 672429 - Deleting Browser History (Ctrl+H) is Fubar'd, Deleting Far More then Wanted

I wish they would have stuck with the simple expiry by date as it was before, the "sophisticated" reasons for dropping that notwithstanding.

[NEW] - Bug #660646 - Restore Capability -- With User Interface -- to Expire History Entries by Age

As partial workaround see Bug #660646 comment 7




Cheers!

[webmoebius]

I have tried the manual workaround shown on comment 7 at this Bugzilla bug record:
https://bugzilla.mozilla.org/show_bug.cgi?id=660646#c7

Using this expression:
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)

and have opened the SM browser error console, paste that entire expression into it and click the EVALUATE button to execute it. It seems to work to some degree, because when I open the history window now I can see that the history category of OLDER THAN 6 MONTHS is now gone, so presumably it got rid of really old history entries. However, I still noticed history entries going back 2 to 3 months, so for some reason the manual purge didn't quite work exactly as hoped since I specified retaining 30 days of history as the cut off point.

I also noticed that I had to run sqlite manager and select the places.sqlite database file and compact it before this file would shrink in size. This present requirement is just simply far, far too advanced for any regular non-technical SM user to perform in order to maintain file size of the places.sqlite main database. I would be nice if in the future SM developers could have some kind of configurable auto compact function for this file so it would be self managing without the user dealing with details this technical, not to mention needing to install an add-on utility like the sqlite manager and learning how to use it.

[Philip Chee]

I also noticed that I had to run sqlite manager and select the places.sqlite database file and compact it before this file would shrink in size. This present requirement is just simply far, far too advanced for any regular non-technical SM user to perform in order to maintain file size of the places.sqlite main database. I would be nice if in the future SM developers could have some kind of configurable auto compact function for this file so it would be self managing without the user dealing with details this technical, not to mention needing to install an add-on utility like the sqlite manager and learning how to use it.

In the latest versions of the Places database in Firefox and SeaMonkey, the VACUUM command is run asynchronously at regular intervals in the background. In addition the Places code does an integrity check at regular intervals.

Phil

[webmoebius]

In the latest versions of the Places database in Firefox and SeaMonkey, the VACUUM command is run asynchronously at regular intervals in the background. In addition the Places code does an integrity check at regular intervals.
Phil

That's great to know. I suppose by the latest version you're referring to SM 2.41 then? I'm still on SM 2.4 and won't be upgrading to a newer version until after the SM 2.5 release. However, I think the auto vacumn function would not help to reduce places.sqlite file size that much until the automatic history expiry by specification of fixed days as previously configurable by the user, is restored to the functionality of SM. For now, the most likely scenario for most users is that palces.sqlite will continue to bloat and not a lot of users will even go into the history window to delete history entries manually. If they did using the history window interface, that would also easily result in the application either crashing completely or take an extremely long time that it would look like the application had crashed, whenever a large number of history entries are deleted. Other than the error console expression I tried earlier, which did wipe out a large number of history entries fairly quickly without crashing the application, it seems there are no really reliable and reasonably fast ways to delete large number of history entries selectively at this time.

[therube]

(Uh, expecting any sort of specific codec to work, or expecting the way a browser works, after 5 years, is pushing it. Locking .)

[James]

webmoebius, I splitted your post off as a thread thread at http://forums.mozillazine.org/viewtopic ... &t=3026313 as this thread is from over fives ago.