At least Firefox gives proper suggestions from history when typing in addresses. Chrome is way off, as if it wants you to search in google instead.

That's the main reason I've always stuck with Firefox. I use the address bar as a way to quickly access my history instead of using bookmarks, and it has worked so well for me so far.

Actually it only gives a limited numer (10 or so) hits from your history. I remember years ago, this wasn't the case and you could keyword search your history/bookmarks and the dropdown would get longer and get a scrollbar, but you could actually scroll through 100s of hits that way.

I used that a LOT, and I'm still sad they removed it for some reason. 10 is very often not enough, because it lists too many similar domains.

It is possible to get that feature back with two advanced tweaks (which I had to use):

1) Increase the number of results in about:config: Set browser.urlbar.maxRichResults to your desired value (like 60).

2) Make the results scrollable with a userchrome.css tweak: Using this example or your own: https://github.com/MrOtherGuy/firefox-csshacks/blob/master/c...

Yes, I also notice that I often don't have to go to Google because the page I need is in the dropdown. Suggestions in FF work awesome.

If I enter "gov.ie" in Chrome, it will search for it rather than going to the address. So annoying.

> "and deletion of swaths of entries is impossible as it makes the history manager UI hang for many minutes or even hours (=essentially I always kill Firefox when I do this by mistake). I suspect the GUI constructs a view of the sqlite db using single GUI objects tied to single DB entries and therefore has maximum overhead."

I've not probed this deeply, but I have encountered it and can confirm it's a problem. To give an idea of the magnitude of the problem, deleting 10,000 history items can easily lock up Firefox for a full hour. I think but haven't confirmed that it might even be nonlinear. e.g. deleting 1,000 entries 10 times in a row seems faster than deleting 10,000 entries in one go.

I don't know what firefox is doing here, but it's badly broken.

(My places.sqlite is 55MB)

so i did a little bit of digging into it and it looks like it does a delete command for each of the items that are selected in the list separately. this is all overly simplified as there are other things going on (selecting the nodes to be deleted as well as notifications to other subsystems.)

That item can be a node(website) that has thousands of visits associated with it so it needs to then delete each of those in multiple batches of delete statements chunked by the db variable limit(~100 or 1000 I think).

Then after that transaction sqlite rebuilds the indexes(17 by my count) on the database with those items missing.

then it does the next chunk and continues on in chunks until there are no more items to delete and then the next item that was selected begins the process again. there might also be a problem with redrawing the history list taking time away from the deletion itself too. it's tough to say exactly what the full bottleneck it but the chunking of the deletes like that looks like a culprit.

Firefox is deleting each entry individually. I tried to contribute a patch with a short-circuit when you select all and hit delete, but the places code was in the middle of a refactoring, and as always with browsers it was way more complicated than my patch, so it wasn't accepted.

Are you aware if there's a bug open on bugzilla for this?

I confirm it too. it's very annoying.

I also had the same desire as you to keep my firefox history for as long as possible. It's especially great for auto-completion of previously visited websites.

My places.sqlite file is several years old and has moved across several machines, it is 47MB.

I can't say I've experienced the same lag you're describing. At least using the firefox url bar ( where auto-completions show up ) I found it to be pretty quick. The firefox history management window "feels" a little old ( read: 90s ), but is functional for the times I've had to search for a site I visited 5 years ago and vaguely remembered the name.

What specific features would you want to see from firefox's history management window.

Make a copy of your profile (to preserve your history) then in Firefox's Show All History window, search for a site that has thousands of visits, select them all, then press delete. Firefox will start burning a few CPU cores and lock up for a long time, every time.

That might very well be performing poorly. But I interpreted the OP to talk about usability of viewing all the previous history. My goal is to never delete my firefox "sites visited" history so I can refer to it back later. So naturally I've never experienced the problem you're describing.

My places.sqlite is 400MB, and just opening the history viewer is enough to cause Firefox to hang for several seconds. It's really not designed to store history forever; I even had to change places.history.expiration.max_pages and places.history.expiration.transient_current_max_pages in about:config to prevent it from deleting old entries.

No I meant deleting items takes a very long time, like the current grand parent.

Search is quick, in Ctrl+H and the URL bar suggestions are instantaneous. No complaints there.

you can try going to your profile and running:

sqlite3 places.sqlite vacuum

to see if that helps speed things up a bit. might not but it's free and safe(well as safe as anything can be i guess).

to your other point if you want to check this out you can likely use an artifact build to compile firefox in under a min or so if the changes are only in the javascript frontend code and not the backend c++ code. (unsure where the slowdown is)

Vacuum has no substantial impact here. It only knocked about 10% off my places.sqlite and mass deletion remains pathologically slow.

perhaps you can file a bug about it? should not be that slow.

here are a few of the places where it's being deleted by the looks of things:

https://searchfox.org/mozilla-central/search?q=history+delet...

it's in javascript so it could be debugged with an artifact build perhaps?