Hya

Problem Firefox (Web Content) eats up huge memory, on Debian (testing, AMD64).

Question Does anybody run into same situation? How to troubleshoot?

Troubleshooting So far, I have not found what triggers this situation. Killing "Web Content" crashes some open tab, but inconsistent. I have several Debian's around. It looks like only one of them is affected.

With web search, I have found several sites, which are several years old. mozilla site says "update firefox". StackExchange site explains what goes on, and use noScript plugIn. The former is of not much help, the latter works with side effect, -Javascript does not work!- so not practical.

I am wondering if anybody else runs into same situation. And can anybody direct me to next step?

cheers

What particularly do you mean by "web content." For example, is it cookies, history, cached data, or something else?

Or are you perhaps referring to the "web content" item in top (or a similar application), as referenced in this discussion on the Ubuntu forums? Given the large amount of scripting on web pages, the presence of video and audio pop-ups, etc., web pages can use a lot of RAM to display, especially if you have a number of them open. In addition, per the link above, certain Firefox add-ons might contribute to RAM usage.

mine says 82g virtual memory .. what up with that

Just for grins and giggles, here's mine:

I have five tabs open: three for my website, one for my hosting provider (not currently logged in), LQ, and the Ubuntu link I cited above.

Web content is web content, I've seen reports just opening one bloated web page eating up 400 MB of memory. Disabling javascript is practical, you can fine tune your most visited web sites and make them look useful, without floating videos and other annoying content. I keep uMatrix enabled at all times and web sites look almost sane in my browser.

Yes, I run into it often, but even though the rendering engines are poor and inefficient, it has more to do with the javascript infecting what has replaced the modern web. I'm not sure if a tipping point has been crossed and that we have no way to repair the web. It's been noted for years and years. There are some grassroots initiatives here and there to try to reduce or eliminate the bloat. The 512kB club is one.

It's a matter of education and almost no one anywhere is willing to invest in education these days, especially ICT, and especially web design.

The push towards bloat also comes in part from Google/Alphabet and their search engine, along with the droves of posers, frauds, and charlatans pretending to be web developers yet producing only copious amounts of client-side javascript instead of HTML+CSS. Google is big enough to stop that in its tracks through its search engine ranking algorithm, yet it chooses to endorse that crap. Part of the reason for the endorsement is that it pushes people into accepting Google AMP for some temporary, short term gain in exchange for total loss of the Web.

However, that is more of a rant than intended. The bottom line is that about all you can do is take your business to another site and, if possible, let the failed site know why you voted elsewhere with your wallet. The fault is not entirely with your browser but more with what is delivered to it.

You might look at NoScript and be selective and minimal about which scripts are allowed to run.

C'mon, don't hold back - say what you really think ....

I did hold back quite a bit, and even edited a little.

The point of contention is that the web grew as a commodity. The skills and technologies to create, use, maintain, and extend sites were common and interchangeable. It was also fairly secure from the client perspective, unlike client-side javascripting. Not only are there security, interoperability, accessibility, and usability problems introduced with client-side javascript, you also have the core problem of the site no longer being made from commodity technology. More can be said there, but the gist is that it leads directly to the bloat mentioned in #1 above. The cynic in me says that is just a taste of what webassembly will be.

Hya

Thanks for replies;

It does not sound like that there is a straightforward solution without side effect(s). Network world is still under development, I guess.

Have a happy Penguin!

cheers

firefox will (be able to) kill the system if you want to display a huge text file. No css, javascript, whatever involved, just a simple plain text file.

Hi. More interesting. But can you summarize the way to solve de memory problem?
Have a nice day.

This memory leak has been around quite a while. A few days ago I was uploading some files to cloud storage while editing text. Not a lot of load you'd think. Then the system would freeze for a second or two. After this happened a few times I went into task manager and it was using a whopping 2.5gb of 4gb. As soon as the upload finished I closed it and used another browser, Falkon.

This was running on a live usb, but still, 2.5gb?

Hya
It looks like that many penguins run into same situation. For the time being, I go with LU344928, falkon, and see what happens. It looks it is mozilla based and similar interface.
cheers

Yup, I would expect most people do. Mozilla made grandiose statements years ago about making Firefox more lightweight, and they backed that up with good releases. But since then things have just gotten worse and Firefox is bloated and a resource hog, and Mozilla have changed their stance. They now say "unused resources on a computer is bad, we we must use them even if we don't need them". That's their new policy.

I've always used noscript, and it works very well to limit and accept per domain javascript, so your statement it blocks all javascript is wrong. You can accept per domain and cut useless javascripts. You need to actively maintain your noscript policy!

I've tried many things to tame Firefox, with little success. Even so far as to run it as 32bit in a 32bit virtual machine, but it's so resource intensive that unless you give the virtual machine ALOT of resources it will be laggy and unusable. And that was a VM for just running Firefox. So the middle ground solution seems to be running Firefox in a container. I've not tried that, only partly with resource limited execution and partial sandboxing with Tomoyo LSM. Limiting RAM for Firefox to 2gb didn't seem to help, as it hit that limit rather quickly and still seemed to believe it had access to 8gb.. I blocked most access to /proc and /sys, but it still finds the real memory info somewhere and think it has access to that. This makes it crash rather quickly at 2gb.

Anyways, I had enough of Firefox already. So I switch to Konqueror, and doing the same things there takes about 1/2 of the resources that Firefox uses. In fact, just loading the GUI elements and a blank Firefox page seems to take up as much resources as a Konqueror window with a bunch of stuff going on. I hardly ever reach 2gb with Konqueror, and with the new QT WebEngine it's a very fast and lightweight browser, but still lacking some features (so please send feature requests to KDE!).

1 members found this post helpful.

Hya

I am not sure if this is related, however, firefox may not respond to key/mouse input when entire system goes hibernate/resume. It works again if killed by xkill and restore old sessions.

These days, I am trying falkon and Konqueror.

1 members found this post helpful.