The only drawback I have with FF nowadays is history management.
I have enabled 'infinite history' (do not delete old history, ever) so I can keep a journal of what I've visited when. The history, as large as it might turn out, is just a few MB of an sqlite3 database (places.sql) -- problematic is the management of it using the Firefox UI. Searching is laggy 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.
Editing the places.sql file directly via the sqlite3 CLI (with Firefox shut down) is a matter of (milli)seconds at best.
If I had the resources to compile FF in reasonable time I would give developing the patch a shot myself, but browser development is not an option with my current hardware, and I do not have a build server set up.
PS. The fact that Chrome does not support tagged bookmarks is another nail for its coffin. Makes it impossible to organize 10000s of bookmarks, and search on them.
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.
> "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.
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.
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.
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)
I have enabled 'infinite history' (do not delete old history, ever) so I can keep a journal of what I've visited when. The history, as large as it might turn out, is just a few MB of an sqlite3 database (places.sql) -- problematic is the management of it using the Firefox UI. Searching is laggy 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.
Editing the places.sql file directly via the sqlite3 CLI (with Firefox shut down) is a matter of (milli)seconds at best.
If I had the resources to compile FF in reasonable time I would give developing the patch a shot myself, but browser development is not an option with my current hardware, and I do not have a build server set up.
PS. The fact that Chrome does not support tagged bookmarks is another nail for its coffin. Makes it impossible to organize 10000s of bookmarks, and search on them.