Firefox keeps getting worse

WARNING: RANT with questions.

It's been a long time since Mozilla chose to break most of the useful addons with the Quantum update and the deprecation of the old addon API. One of the positive things about that mess was that it pushed me towards uBlockOrigin and uMatrix after NoScript was bricked and AdblockPlus started to block only some ads.

But I still have not found a useful replacement for DownThemAll. There is still no promising development towards a working version, but according to Nils Maier's comments on Patreon there are lots of issues with the WebExtensions API that hard/impossible to fix.

More and more websites stop working with Decentraleyes because the necessary changes to the WebExtensions API (https://bugzilla.mozilla.org/show_bug.cgi?id=1419459) have been classified as enhancement (i.e. will not be fixed ever) although the problem has been approved during the regular triage meetings almost a year ago (February 20, 2018). This is an addon that has been featured by Mozilla. I'm not sure that they still use it to promote the use of Firefox or if they stopped doing that, but I'm not willing to dig through that monstrosity of a website.

IMO forcing the premature use of the WebExtension API was a huge mistake when they have not been able to fix its problems more than a year later.

Let's forward to the latest version. Even if you have the separate search bar enabled it started to display the same search engine selection box under the address bar as soon as some text is entered in the address bar. What is the point of having two bars if one of them can do what the other one can in addition to its own functions? Someone else asked the same thing on Mozilla's help forum. Some community moderator linked to unrelated help articles without reading the original question.

The visited places are still kept in a SQLite database when an article on the development wiki that is several years old states that such data should not be stored in a database. On my system that mistake accounts for almost half of Firefox's memory footprint. On top of that it can cause almost 100 % CPU usage during selective purging of the databases consents. Unfortunately I cannot disable that functionality completely, because there are two websites that I frequent that only have the link color as an indicator of read posts.

There is Firefox's (some old version) fork called Pale Moon. I use its mod called New Moon. Works flawlessly, had no problems with it. https://o.rths.cf/palemoon/?sort=date&order=desc

I stopped using Firefox when it pushed my 4GB RAM Dell laptop to the brink of ruin upon startup. Can't imagine how worse it has gotten. 

On 2/6/2019 at 3:49 PM, Mr. Freeze said:

I stopped using Firefox when it pushed my 4GB RAM Dell laptop to the brink of ruin upon startup. Can't imagine how worse it has gotten. 

Yup, that's the same time I stopped using it. My browser doesn't need to be using up 2GB of RAM. Right now I'm on Chrome and it's using 400mb of RAM. I've heard that it's gotten so much better over the years, and it stopped using so much RAM; but I've never seen a reason to go back and try it again.

I use Waterfox and I have none of these problems. Maybe you can try it?

On 2/6/2019 at 11:15 AM, Manuel-K said:

The visited places are still kept in a SQLite database when an article on the development wiki that is several years old states that such data should not be stored in a database. On my system that mistake accounts for almost half of Firefox's memory footprint. On top of that it can cause almost 100 % CPU usage during selective purging of the databases consents. Unfortunately I cannot disable that functionality completely, because there are two websites that I frequent that only have the link color as an indicator of read posts.

Perhaps you could explain this in a bit more detail because it doesn't make a lot of sense to me. I wouldn't expect sqlite to account for half the memory footprint - where are you getting your numbers?

5 hours ago, fraggle said:

Perhaps you could explain this in a bit more detail because it doesn't make a lot of sense to me. I wouldn't expect sqlite to account for half the memory footprint - where are you getting your numbers?

From lxtask/top.I got that number from the memory usage before purging the data and after purging the data. It seems that the way Firefox uses SQLite is really inefficient. During the purging process memory usage increases temporarily by several GB.

But that is basically what the Mozilla document stated as well.

----

The thing is: Phoenix (as it used to be called when I started using it) was intended as a light and fast replacement for Netscape Navigator. And it stopped being that a few years ago. It has a huge amount of stupid cruft (pocket, sync, screenshots, integrated ads/“targeted user information”, etc.) added on top of it while useful options (like the old new tab page) get deleted because of branching paths in the code.

I don't think using a fork is a good idea, because those don't have the manpower to keep up with security fixes. Chrome/Chromium is a privacy nightmare and lacks settings to remove some glaring UI annoyances.

On 2/7/2019 at 12:49 AM, Mr. Freeze said:

I stopped using Firefox when it pushed my 4GB RAM Dell laptop to the brink of ruin upon startup. Can't imagine how worse it has gotten. 

I also stopped using it ever since I got my new PC. The first thing I noticed after the upgrade was that it was running only a bit faster compared to how it did on the toaster.

Are. You. Serious? From a relic to a mid-range rig and it wasn't that big of a difference from a performance standpoint? Except for playing hd 60fps videos, alright, but everything else felt... slow.

8 hours ago, Manuel-K said:

From lxtask/top.I got that number from the memory usage before purging the data and after purging the data.

I'd be dubious of this without rigorous investigation and deeper understanding of how the memory is really being used. If all you did is look at some numbers in top I doubt you're properly understanding what you're looking at.

Bear in mind that RAM may be affected by other factors which can act as proxies for the database size, for example:

• If you do something like clearing your browsing history that often also includes clearing caches which are unrelated to the SQLite files which store the history.
• Memory may be used for the search bar to provide suggestions based on past browsing history. But this has nothing to do with the choice of SQLite as history store.

It's entirely possible that you're right of course but it doesn't make any sense to me at all that the size of an on-disk SQLite database would have any relation to the process's memory usage.

But does it really matter if the performance problem stems from the way the Mozilla's storage abstraction uses SQLite or some other inefficient thing Firefox does? Notice that I never blamed SQLite for the problem. I suspect that the main thread creates a huge amount of database connections during the removal of visited sites. Each one of those might run a purge after every dropped item. That would account for the spike in memory and CPU usage. I have to admit that I'm not motivated enough to waster more time on this annoyance by throwing a debug build into gdb or something similar. Regarding the huge amount of memory the visited places data seems to require during normal usage might point to inefficient database queries for each link in an open page, but that is pure speculation.