Closed Bug 643254 Opened 14 years ago Closed 14 years ago

bring back temporal history expiration settings

Categories

(Toolkit :: Places, enhancement)

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

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: al_9x, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 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. 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 Reproducible: Always
Version: unspecified → Trunk
(In reply to comment #0) > > so all that you've done is make the pref suit the code and not the > user I am referring to the current sole expiration threshold pref: places.history.expiration.max_pages http://blog.bonardo.net/2010/01/20/places-got-async-expiration
(In reply to comment #0) > > you don't need anymore to tell us how much days of history > > your computer can handle. > > 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 No, it doesn't miss the point, the most common use-cases for users to determine a value were: - privacy: fake sense of privacy, by limiting history to a few days. - performances: wrong idea that having less history makes the program faster. - location bar matches: rather than improving searches, reduce data. All of the three concerns are based on wrong ideas or mis-comprehension of the underlying features. The user should be put in front of a choice only when any possible choice will create tangible user's disadvantages. In this case, history limitation was artificially added in the past to workaround hardware limitations, when the platform was mostly flattened (not having to run on desktop, laptop, netbook, tablet, mobile). As of today all of these conditions became untrue, we can retain lots of data with small perf hit, we have better tools for privacy, we can adapt to the device and there are lots different devices in the market. The disadvantage for the user is he has to manage his private data for real, by deleting meaningful stuff, rather then relying on fake-privacy feelings. Also sometimes searches in the location bar could return more than he needs, but that's easily work-aroundable by improving the search terms, instead in many cases bad searches will return something meaningful (that is a gain for most users). Pretty small disadvantages to have to put the user in front of a not completely understandable choice (what does 10 days means compared to 2 days or 30 days? Do I have more or less data? will this drop data I care about? will that number be fine for my privacy needs? will it ensure more or less privacy in my specific case? What to choose to get better search results?). So, if you have use-cases that don't fall in the 3 points I made above, I'm happy to hear and discuss them, otherwise I think all of this has already been explained many times.
If you're suggesting that the users are confused by the notion of the browser forgetting about pages they have not visited for a certain period of time, that's nonsense, it's a very intuitive and simple idea. Regardless, we are discussing a hidden setting, expiration.max_pages, which I maintain is meaningless, and hence useless, to human beings, whereas a time based setting (expiration.days, even if hidden) would be meaningful and useful. If a user believes that pages they have not visited for {some configurable period} are not relevant and useful to them, who are you to insist otherwise? Imagine your history is full of Mozilla visits, and then you switch to Chrome, and stop visiting the Mozilla pages, at some point they become just useless noise (consuming storage, memory, cpu when searching, user's time by distracting them in results and increasing search time) and therefore best forgotten. Forgetting about pages that user shows no interest in for a long time is sensible and useful (for many)
(In reply to comment #4) > If you're suggesting that the users are confused by the notion of the browser > forgetting about pages they have not visited for a certain period of time, > that's nonsense No, that concept is really simple, what users have an hard time guessing is how changing that behavior (by setting fixed amount of days) changes their data in non predictable ways. , it's a very intuitive and simple idea. Regardless, we are > discussing a hidden setting, expiration.max_pages, which I maintain is > meaningless, and hence useless, to human beings, whereas a time based setting > (expiration.days, even if hidden) would be meaningful and useful. Indeed it's an hidden pref that exists only because it has almost no cost maintaining it, differently from a days pref. > Imagine your history is full of Mozilla visits, and then you switch to Chrome, > and stop visiting the Mozilla pages > > Forgetting about pages that user shows no interest in for a long time is > sensible and useful (for many) And we provide ways to remove exactly what you want (thus for example the mozilla domains), rather than delete random pages from your history just because they are old, that per-se just means it has not been visited from some time, not that the user won't be interested in finding it now or tomorrow or in the near future (Indeed I'm now looking for bugs that I last read 1 year ago in my locationbar and I'm interested in those, I'm looking for an article I read 6 months ago because today I found another article talking about similar stuff, and so on). If there would not be any limit on hardware we could never expire anything, the limit exists merely because resources are limited. So far, this doesn't add anything to what I said, We are exchanging random cleanups that will MAYBE or partially remove the stuff you don't need for meaningful cleanups that will FOR SURE remove the stuff you don't need (in your example I'd prefer removing all mozilla.com pages manually rather than relying on my choosing a decent days expiration to guess that maybe the browser could remove a major part of them for me). Sure this requires more attention from the user, but after all users who don't care about data still can avoid caring, and users who care about data should not mind spending that bit more time cleaning it up properly.
If you don't want to expire anything in your profile, I am not stopping you, it is you who are stopping those who do. Nobody is interested in manually pruning their history on regular basis, those who consider old visits no longer relevant want them expired automatically. There is nothing "random" about properly implemented temporal expiration. It removes pages that a user has not visited in a long (configurable) time.
(In reply to comment #6) > If you don't want to expire anything in your profile, I am not stopping you, it > is you who are stopping those who do. You are not providing sufficient justification to make this change. To be clear, "I want to be able to expire history by date" is not sufficient.
(In reply to comment #7) > You are not providing sufficient justification to make this change. To be > clear, "I want to be able to expire history by date" is not sufficient. You have removed functionality that people use and like, that's been in Fx from its inception. It is you who need to justify its removal. And your justification of "nobody really wants to expire history" is a lie, people do and I explained why.
(In reply to comment #8) > You have removed functionality that people use and like, that's been in Fx from > its inception. It is you who need to justify its removal. This isn't a democracy (it's a meritocracy), so just because you aren't satisfied with the reasons given, doesn't mean we need to come up with more reasons. > And your justification of "nobody really wants to expire history" is a lie, > people do and I explained why. Macro hasn't said that. This feature request sounds like good idea for an add-on.
(In reply to comment #4) > Forgetting about pages that user shows no interest in for a long time is > sensible and useful (for many) Exactly. The criteria for interest that is used in the expiration code is based on a many factors, of which age is one. Age by itself is not enough, as Marco has explained in the above comments.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Not allowing us to configure the time a history item expires really stinks. To me, and a lot of others, it simply feels 'broken'. It's not just about privacy or false sense of security. When I start to type into the [now less than] Awesome Bar I expect to see, among other things, "urls I've visited"... not "items that make me feel less secure because they have not yet expired from my history". I understand the other criteria for expiring history items. But not letting us change those params is bad for a lot of us. Over time a company will modify a product for the users benefit. Normally that means adding, enhancing, or simplifying. Not usually taking away. After upgrading to 4, I type in "prototype api" and I no longer see http://www.prototypejs.org/api. I was there last week. This is not better. This is broken.
Taking control away from the user and assuming you know what the user needs is almost always bad design. What's next? Are you going to remove the user's ability to bookmark pages because you know what sites they should have bookmarked? I had this option set to keep history for 30 days not because I thought it gave me some privacy but because if I hadn't visited a site in over 30 days, I no longer care about it. If I thought it was ever going to matter to me again, I bookmarked it. Please bring this option back.
I totally agree with al_9x@yahoo.com points - I am really skeptical about seeing FF starting to make choices for the user ! There is really no justification for taking this feature out - apart from being difficult to code apparently - while I don't mind a bit of automation for err "computer challenged" people you should make the extra effort and keep the options there for whoever wants them. I repeat : having the ability to decide *when* a url is no longer needed to be remembered is a nice FF *feature* which is not available anymore !
We didn't remove a feature, we removed a limit that was not bringing any real gain to the users, but was bringing a lot of confusion to them instead. And the limit was introduced as a limitation of the code, not as a feature ("we can't be fast enough, then have the user figure out how fast we can be"). Making decisions for the user is absolutely fine, if if it's a good decision for most of the 400 millions users. Historically any change had someone against it, and that is fine, nobody tries to hide dissent or stop the discussion. Still, so far nobody has brought any valid reasons apart "I want to be able to do this", and the general feedback on this was globally silent, that means that most users just don't care. We had a general good feedback on performance improvements instead, so globally the change was a win. An extension can be made to expire visits at a timestamp, it would regress performances and uselessly reduce the available data for the awesomebar, but as far as the user is informed of that, it will be fine.
Excuse me - why "I want to be able to *see links as visited* after one year" is not a valid user case ?!? Please stop hiding behind the "majority of users" - the majority of users is using IE, the vast majority of users don't know where the options are (like all my elder relatives). But there are users of FF - more than any other browser - who appreciate a good piece of software. And I assure you that once more of those users understand what has been done with the history settings they will start complaining. I realized this just today. Do you understand that *I lost two years of browsing history*, faithfully kept ? Most of your replies are for people setting the history limit low - did it really not occur to you that some of us had this setting *high* ? This was a very "inelegant" decision after all - really MS like - making assumptions for the user that conform to a "majority" - one that resulted in information loss moreover. Please reopen the bug.
You can tweak the preferences to store more history than the default, that's why my replies are for people setting the limit low. I assume you know you can just set places.history.expiration.max_pages to a really large value, and you didn't come here to complain without first checking what you could do. And we retain more than 1 year of history for most users on modern systems, something we were not doing before. Clearly once you do this change, if you have performance issues you should not file a bug, since you're explicitly asking for worse performances against longer history.
>Still, so far nobody has brought any valid reasons apart "I want to be able to do this" You have not provided any reason for removing this option other than "We wanted to remove it". You claim that this was done in the name of performance. It has been my experience that when developers try to determine what my computer can handle as far as performance goes, they always over estimate. This current situation has been no different. Since installing Firefox 4 I have been experiencing hangs in the program. Firefox would just hang for a couple of seconds and then would become responsive again. This has gotten worse and worse as I've used it to the point that I considered migrating to another browser. I just recently set the places.history.expiration.max_pages setting to about 1/8th what you defaulted to and Firefox is now running smoothly.
Marco has cited many reasons for the change in this bug. If you disagree with them, that is your right. We are not going to revert this change. If you want to revert the change, write an add-on to do it. All the APIs to do so are available. Ask questions in #places on irc.mozilla.org if you'd like help. If you'd like to continue to discuss this further, please take the conversation to the dev.apps.firefox newsgroup/list. Dietrich (module owner of Places)
(In reply to comment #18) > You can tweak the preferences to store more history than the default, that's > why my replies are for people setting the limit low. I assume you know you can > just set places.history.expiration.max_pages to a really large value, and you > didn't come here to complain without first checking what you could do. > And we retain more than 1 year of history for most users on modern systems, > something we were not doing before. > Clearly once you do this change, if you have performance issues you should not > file a bug, since you're explicitly asking for worse performances against > longer history. I definitely can't set it to 9999 *days* - a time scale is needed once again. Is this really difficult to understand ? Have a look at the posts at your blog. Moreover once one upgrades he/she/it will loose his/hers/its history == bug ! I went ahead and set the places.history.expiration.max_pages to 99999999 but that did not help recovering my history, of course. Look I appreciate adaptive algorithms but as one put it in your blog : "I don’t want an adaptive algorithm to decide for me, I know what’s best for me, don’t go around crippling the browser for everyone because uneducated users can’t bother reading documentation: set a default and let power users tweak whatever they want." Adaptive algorithms for a setting that used to be in options ? No no.
(In reply to comment #19) > Since installing Firefox 4 I have been > experiencing hangs in the program. I > just recently set the places.history.expiration.max_pages setting to about > 1/8th what you defaulted to and Firefox is now running smoothly. There is no evidence of a relation here, apart that changing the setting could have worked for a temporal coincidence or a faster cleanup of a broken/corrupt database. You should have filed a bug for your specific case at that time. Since it's the first time I hear this complain, with more data we could have figured out the issue, that I hardly think is related to these numbers. Can you provide me your system specs at least? I suppose you don't have anymore your old database for analysis though :( (In reply to comment #21) > I definitely can't set it to 9999 *days* - a time scale is needed once again. Still no reasons provided, moreover in your case a time scale is completely useless, since you bypass it by setting 9999 days. > Is this really difficult to understand ? Have a look at the posts at your blog. I do everyday, since I consider feedback important, but 10 users complaining is not a representative of a mistake, just something to think about (and we do!). > "I don’t > want an adaptive algorithm to decide for me, I know what’s best for me", don’t > go around crippling the browser for everyone because uneducated users can’t > bother reading documentation" People saying "I know what is best for me" most often don't, just because they lack knowledge of the underlying architecture and its possibilities. Setting history to 9999 days or 99999999 pages is exactly what a user with knowledge of the system would avoid. The pref was asking the user something he was unable to guess, without a long study of the source code, the new prefs are hidden exactly because of this difficulty. > Moreover once one upgrades he/she/it will loose his/hers/its history == bug ! Setting history to 9999 days was a not officially supported "push" of the history limits. We are considering cases where the history loss was unwanted (like a user with 8 thousands boomarks on a really old system) as real bugs, obviously. Can I have your system specs and what your transient_current_max_pages was before changing it? And possibly how many bookmarks you have and how old was your oldest non-lost visit. Let's try to make this constructive please.
"Officially supported" : of course it was : it was the way to tell FF "don't ever delete anything". I would prefer to set it to -1 but there was no such option. System specs : I am using the same profile in 5 machines - the last one was transient_current_max_pages=~31000, but IIRC the previous one transient_current_max_pages=~190000. Anything from EEEpc/1gb RAM to i7 950/6 gb. "Know what I'm doing" : I do - it's the way I work - I need to know what I've visited - I did oftentimes go to history and manually delete some 1000nds of records (gmail for instance) - or set sites to be ignored - etc. I felt the performance loss - but I *chose* it. 2 was worse than 3. Bookmarks not much as I was using Scrapbook. I am afraid that my oldest non lost visit was from last week - I had corruption issues - not sure when/why. Investigating - happily Dropbox has one month worth of backups. Time vs pages : please consider again feedback - I set it to 9999 (-1) but other people set it to 365 - it made sense to them (me). 10 people complaining : I think that's enough. Another 1000 won't bother and 10000 don't know how to open the options. Thanks for listening
(In reply to comment #23) > System specs : I am using the same profile in 5 machines This can be problematic, indeed profiles are not intended to be used across different boxes, and they were never meant to support this. You should use the Sync service to bring information across machines. > transient_current_max_pages=~31000, but IIRC the previous one > transient_current_max_pages=~190000. Anything from EEEpc/1gb RAM to i7 950/6 > gb. Both values seem ok for their uses (accounting for 365 days to do a simple guess, would be 85 unique pages per day on the netbook and 520 pages per day on the i7). I think you've lost your history by using the old profile on the netbook, this has caused the profile to be adapted to run on a netbook, most likely reducing history to 6 months (my guess). Managing 190000 unique pages on the netbook would have been a perf nightmare, that is one of the reasons behind the change.
(In reply to comment #24) > This can be problematic, indeed profiles are not intended to be used across > different boxes, and they were never meant to support this. You should use the > Sync service to bring information across machines. Nope - Sync - well we won't discuss this here. Anyway maybe you should start thinking that people are indeed using DB to sync their profiles - and it works perfectly well - apart from some details. I think FF devs should keep this under mind - until they make Sync sync extensions, styles, settings, etc > I think you've lost your history by using the old profile on the > netbook, this has caused the profile to be adapted to run on a netbook, most > likely reducing history to 6 months (my guess). Managing 190000 unique pages on > the netbook would have been a perf nightmare, that is one of the reasons behind > the change. Once again : the nightmare for me is to loose my history ! Please please please accept this ! I know all about lag and I love it - and I have a mini profile on the netbook I use whenever I want speed. I lost the history when I accidentally run 3.6.16 on my XP machine on FF4 profile. I have the places.sqlite.corrupt and I'll try to hack my history out of it when I get some time. I don't blame FF for this - plain stupidity on my part. What I blame you for is not letting me have as much lag (history) as I want (need) ! Please listen to your users. You might put a warning like "700 days of history will be lost ---Ok--- ---No, run the limit up--"
FWIW, I liked being able to set the time limit, usually 2 days just to keep the clutter out of the URL window. Not sure what we think was gained by its removal, and I'm betting "the majority of users" pay little attention to most of the tweaks available in the program.
(In reply to comment #26) > Not sure what we think was gained by its removal Suggest reading the above 25 comments then...
Oh, I did. The ones that stuck out were those that suggested the users who cared just spend the time to manually prune rather than spending the time once to add the few lines of code back in. Don't blame everyone for being a bit miffed by that. The other reasons are far weaker. I like the program, I do, and appreciate the time spent writing it. And, of course, the final decision rests with its authors. If a few of those writers are the ones defending the feature removal, let me say "thanks," but you aren't listening.
From what I can understand of the postings here, it seems that Marco has confused the functionality of the history feature with that of bookmarks, at least from a user perspective. As a user I will bookmark any page I see long-term value in. The reason I would set a time limit on my history (I suppose a page limit works too, but is less intuitive as a user) is because the only time I go to my history is to locate a page I did not bookmark, but then recently found value in re-visiting. Anything I visited longer than, say 30 days ago, I will probably not remember anyway, and certainly not with enough specificity to go digging in my history for it. As for why I would want to limit the amount of data, this data is taking up space on my hard-drive (along with little and not-so-little bits from so many other programs), and I'd like to set a simple feature that cleans it for me instead of relying on my (as alluded to earlier rather poor) memory to clean it periodically. Finally I think one of the comments made by other users was unfortunately glossed over, but deserves much attention in the "the customer is always right vein," being that if users want this option, then it should be included. I realize this is a free product, and I appreciate the work and effort that goes into making a better browser - but even still it's bad form to insult us and tell us what we really need or want.
(In reply to comment #29) > From what I can understand of the postings here, it seems that Marco has > confused the functionality of the history feature with that of bookmarks I can ensure you I understand the module I'm working on, but you are welcome to join us, write patches and plan features, that's the good part :) > The reason I would set a time limit on my history (I > suppose a page limit works too, but is less intuitive as a user) is because > the only time I go to my history is to locate a page I did not bookmark, but > then recently found value in re-visiting. Yes, and this is mostly unpredictable, you can't tell today what you'll find value revisiting in 30-60 days. We move towards webapps, and those can store data forever if they wish, as any app. And you can cleanup that data if you wish. History works just the same, the expiration exists only to ensure the user performances are not ruined, otherwise any browser would want infinite history (Chrome, the most recent born browser, has something like that). > Anything I visited longer than, > say 30 days ago, I will probably not remember anyway, and certainly not with > enough specificity to go digging in my history for it. Right, that's what the awesomebar is about, finding stuff for you, without you having to dig into history. > As for why I would want to limit the amount of data, this data is taking up > space on my hard-drive (along with little and not-so-little bits from so > many other programs) Freeing up some megabyte is no more a valid use-case nowadays, data storage is cheap and often attention goes toward less offenders. Most users would be surprised of seeing how much garbage apps keep in temp folders, but rarely someone cares about cleaning up those gigabytes. At least we retain data the user has an use for, not garbage. We plan to do a data shrink in future, to retain even more specific data and make the db size even smaller. > and I'd like to set a simple feature that cleans it > for me instead of relying on my (as alluded to earlier rather poor) memory > to clean it periodically. This is implemented. The required manual effort on your side is just to remove what you care about for your privacy. This is not something any automatic software could do, since privacy is different for anyone. > "the customer is always > right vein," being that if users want this option, then it should be > included. Software development doesn't work like that, otherwise today we'd be bloated of stuff most users would not use. We have 600 000 bugs, of these I could guess half are enhancement requests, would you like to have 300 000 new options? I'd not. The actual real concept is "customer feedback is always valuable, but does not always represent the general need". Thanks for feedback.
I have set the places.history.expiration.max_pages to 999999999 in an attempt to get the max possible history kept - still when I open the history in the section "Older than six months" I only see ~30 pages - which tells me the rest are wiped - I can fill this in as a separate bug but I would appreciate getting some feedback first. This whole mess was introduced because of this bug - so please consider adding an about:config setting - like daysToKeepHistory which when set will simply override the mechanism introduced in FF4 and just keep history for as many days. (In reply to comment #30) > History works just the > same, the expiration exists only to ensure the user performances are not > ruined, otherwise any browser would want infinite history (Chrome, the most > recent born browser, has something like that). Well - I am in for this Chrome approach which could be implemented intuitively like a days setting or clumsily as a pages setting - which I ask for confirmation that it really works... Thanks !
Re comment #3: For users, this RFE is NOT about any of the three situations you throw up as strawmen merely to knock them down. When I view a page containing links, I want the color-code for a "visited" link more than 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, or the list in my address bar, increasing the number of days if I was going to be away from my computer for an extended vacation. Re comment #5: I tried manual pruning of my history. I selected the folder for April and hit delete. My entire history was deleted! See bug #660543.
Status: VERIFIED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
I believe this is actually against Toolkit/Places. Changing from Firefox/Bookmarks & History.
Component: Bookmarks & History → Places
Product: Firefox → Toolkit
QA Contact: bookmarks → places
Severity: normal → enhancement
Please unless you are at least a peer of this module don't REOPEN bugs closed by peers. If you have your own use-cases file your own bug, but unless you bring something new to the discussion it won't get a different resolution though. Re comment 31: it's pretty clear that changing a pref now won't recover you history if it has been wiped before changing the pref. Also if you Sync with another device it may happen (will be fixed in bug 660109). So you issue is not related to this bug nor you need any temporal setting since you already have a pref. Asking a pref to fix a bug is clearly wrong. Re comment 33: there is no strawmen here, there are only major and minor use-cases, each of them get their prioritization, and yes, this means the result may be different from what you expect. Other bugs are clearly unrelated to this.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
(In reply to comment #35) > Re comment 31: it's pretty clear that changing a pref now won't recover you > history if it has been wiped before changing the pref. Also if you Sync with > another device it may happen (will be fixed in bug 660109). So you issue is > not related to this bug nor you need any temporal setting since you already > have a pref. Asking a pref to fix a bug is clearly wrong. Yes - of course it will not bring my history back - I am not idiot - I hope But it does not seem to *keep* *new* history. Please have a look - I do not use Sync And I do have a preference but not the one I need - temporal limit is much more convenient - see the comment 33 on visited links
Please file a separate bug for your case of history not being saved, since it's not related to this bug and it's probably the second report I see in more than 1 year, so not a common issue (The first report was due to a really large number of bookmarks, but in your case it shouldn't matter since you setup max_pages).
Status: RESOLVED → VERIFIED
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)
Is there a difference between this bug and Bug 660646?
The insistance in Bug 660646 on the UI - I do not disagree but an about config would be enough for me
http://blog.bonardo.net/2010/01/20/places-got-async-expiration : The limit will be revised with further tweaks. the 6% of memory has always been in place from Firefox 3, but notice that’s an upper limit. that means that we won’t usually use 6% of memory for history, but that we can’t use more than that. It’s a limit we can’t go over, that’s all. MaK (URL), 26-01-’10 18:30. why you keep all history in ram? sqlite database allows to have data on hdd and not in ram and find it from hdd, right? just it may work long time and heavily if many links on page need to be colored according to whether they are visited, and also when location bar matches work. there can be history that is not used to show visited links, but just for history reasons, and can show visiting history on request with context menu. this can be stored on hdd and be very big. this can be addon. probably firefox team should officially say apologies to users whose history is deleted. who have lost their database should: copy their profile(s) directories for backup, read release notes before upgrade.
(In reply to Dinar from comment #42) > why you keep all history in ram? I have no idea, indeed we don't. If you are looking for browsers keeping all data in ram, you are in the wrong bug tracker :) > probably firefox team should officially say apologies to users whose history > is deleted. Sorry! though I'm not sure what you refer to, the new limits were always larger than the old ones, bugs excluded.
He probably updated from firefox 3 to the one that had this automatic handling of history - so his history was binned - as was mine Yes there should be a big fat warning with a checkbox preventing firefox from deleting user data
This is not a resource question. It is a question of how people work and think. History is useful if I spend a couple of hours or days researching something BEFORE I decide to bookmark what I found essential. Therefore any history older than a couple of days is just trash in my computer regardless of how efficiently it can be handled. Perhaps I am too old to change, but for the past 55 years I have always maintained control over the computers in my possession or care, and I don't want to give that up now to some algorithm I don't personally control or understand.
Is there any problem to measure history database in kB not in number of pages? If not than history could be measured by time, as it is normally, and still Firefox could optimize size of history automatically if a user would choose it.
(In reply to Pawel from comment #46) > Is there any problem to measure history database in kB not in number of > pages? yes, the size of the database is not a good metric for many reasons: 1. fragmentation of the file 2. freelist maintained by Sqlite 3. indices change the size a lot 4. add-ons adding stuff to the database
Metric of what? Performance? Anyway, whether history is measured in kB or in number of pages, the bug can be fixed without compromising advantages of automatic setting history size for most users. It needs adding preference allowing to ignore this automatic setting and than preference allowing for temporal history expiration.
(In reply to Pawel from comment #48) > Anyway, whether history is measured in kB or in number of pages, the bug can > be fixed without compromising advantages of automatic setting history size > for most users. It needs adding preference allowing to ignore this automatic > setting and than preference allowing for temporal history expiration. Such things exist already in my Expire history by days add-on. I don't think it would be useful for the mainstream product.

Firefox preferences offer an all-or-nothing setting for history: "remember forever" or "don't remember at all". Most users stick with the default of remember forever.

After a few months of using Firefox, history list starts to become unwieldy and starts causing problems in browsing and search experience. Here is an illustrative example: I once mistyped a website URL for a site that I love. Now every single time I try to visit my favorite website, the typographical error fake website keeps showing up as top suggestion in the search bar.

Second, typing any keyword in the browser bar shows history links that I visited months ago and bear little relevance to my purpose today.

I understand there are hidden preferences and tricks around this, but perhaps it is time to revisit and reconsider reporter's 10-year old bug request, Marco. Life would be much simpler to have a simple setting of "Remember history for N days".

Flags: needinfo?(mak)

If there are issues with ranking of mistyped pages, we should fix those, rather than trying to workaround the problem by limiting history when it's not the problem at hand.
Ideally mistyped pages should not survive long, but from some time we'd like to make the urlbar stricter in time, so have ranking fall much faster after few days. This a long term project.

The urlbar has historically always tried to provide as many matches as possible, things that are not often visited should just be lower in results.
IF you really want to do that, you can already do it with this add-on I made years ago https://addons.mozilla.org/firefox/addon/expire-history-by-days/

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.