With a sensible watchguard earlyoom, firefox appears to be nearly unusable on lower memory devices
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
People
(Reporter: el, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0
Steps to reproduce:
I am encountering this on the 3GB memory PinePhone with Firefox 91 ESR, I expect depending on the desktop environment used (I use Phosh which I'm guessing to use less memory than regular GNOME for example) this might potentially happen on any 2GB-4GB memory lower spec device.
- Use a Linux desktop on the device
- Install "earlyoom" which is a daemon to ensure the device remains usable and doesn't run into a critical swapping freeze/out of memory
- Make sure to configure earlyoom to discourage it from killing the firefox main process (so it will only do so with the tabs)
- Use any popular, "fatter" website like Amazon's desktop site, Google Map's desktop variant, Youtube, ...
Actual results:
Every 5 minutes or so when continuously interacting with it, the tab of any such non-trivial website will crash even with no other tabs open.
Expected results:
Firefox should at the very least have a setting to make it TRY to cap its memory use. I could be wrong, but since restoring the tab will always work flawlessly and make it workable again. I'm guessing the problem is a fundamental design issue with Firefox. It seems to me it likely thinks it can just keep gobbling up memory for caches and such in a fashion that exceeds earlyoom's critical thresholds, and maybe that isn't inherently wrong since a "good" limit is debatable - but for anyone who would rather trust earlyoom, there seems to be no mechanism at all to tell Firefox to behave more conservatively with its memory use. Alternatively, Firefox could just generally be tuned to use less on such low memory devices for everyone. In any case, it seems like this is only satisfactorily improvable with some change on Firefox's side.
|
||
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
Many websites easily use 500-1000MB just in JavaScript objects. There isn't much Firefox can do there.
You can go to about:memory to see which website is using how much.
When the system fires off a memory pressure event (not sure how this would interact with Earlyoom), Firefox will clear it's internal caches and force extensive garbage and cycle collection. But the reality is that we can't destroy JS objects that 'fat' websites are actively using. It's not clear there is anything actionable here.
I'm assuming the memory pressure event is the problem: I think on Linux there isn't one (or has that changed? I might be behind the times) so if that's true then the "memory pressure event" would be when earlyoom kills the tab off, basically, I think. A fix would be to e.g. allow a user threshold where if firefox reaches it, firefox will do what it would also do with a memory pressure event. Right now, that doesn't seem to be possible so firefox just blindly runs into the threshold and gets its things killed off...
(Just as a side remark, this is also useful on a more regular specs Linux desktop where e.g. launching a bigger Virtual Machine can be impossible or lead to programs being shot down when not closing the browser first, at least if you're the type of user to leave 100 tabs idle. This could also allow power users to limit the browser memory use to not make it go past a couple of gigabytes and then undesiredly block launching of other heavy programs.)
After further testing and thinking, the only uninformed guess I can make just seems to be a downright failure of automatic tab unloading again. Even when I configure earlyoom to kick in ridiculously late where everything chucks already Firefox does nothing until its content is shot down, very often the very tab i am currently looking at.
This makes the tab unloading seemingly useless in practice, or I misunderstood the point maybe? Even if it led in practice to every tab I switch away from to immediately get unloaded it would be a majorly improved experience to constant crash errors. So why is Firefox not at all, ever doing it when it gets hairy? I am very confused.
|
||
Comment 5•2 years ago
|
||
I'm treating this bug as a report about "low memory detection kicks in too late on Android" and moving it to Widget:Gtk (same component as bug 1532955).
This is on Linux, with the Alpine Firefox ESR ARM64 build, PinePhone, compare any ARM64 3GB RAM single board pc. Android I think has a system-side memory pressure event, right? Unlike Linux. Or so I thought
|
||
Comment 7•2 years ago
|
||
Tab unloading has been disabled by default in Linux ~4 months ago (see bug 1780058). In particular after we landed bug 1771712 it was not needed anymore, as we use the Linux OOM killer to the same effect but without the downsides of doing it manually within Firefox. If you are stuck with an old version of Firefox you can disable it yourself by flipping the browser.tabs.unloadOnLowMemory pref.
Well, I'd say the without downsides is extremely debatable in practice if you just read my initial description. I get the active tab(!) shot down constantly with scary crash messages, how is that in any way an acceptable experience? Even if it was an inactive tab I'd be seeing crash messages rather than just a smooth automatic reload of an unloaded page, right? That's confusing and frustrating to the user. It seems as a result like a bad idea to me to not do this in the browser in a controlled fashion.
And Chrome seems to be introducing doing this properly inside the browser too: https://www.bleepingcomputer.com/news/google/new-google-chrome-feature-frees-memory-to-make-browsing-smoother/
This might be the last straw for me to switch over, actually. How FIrefox behaves right now it's just not very usable on lower spec devices, I don't understand how that's somehow intended behavior.
|
|
||
Comment 9•2 years ago
|
||
If you're using Firefox 105+ the active tab should never be killed first, if it is then I'd be curious to know the oom_score of the various processes in your Firefox instance.
|
Reporter | |
Comment 10•2 years ago
|
||
Well I don't use the system OOM killer because it does a really poor job, I use earlyoom. This isn't uncommon. Maybe earlyoom doesn't behave like you think, but then I think the problem is that you assume everyone just has to use the bad system OOM killer.
|
|
Reporter | |
Comment 11•2 years ago
|
||
Oh, seems like I used Firefox 91 anyway, see initial post. And earlyoom according to its README will adhere to oom_score. Nevertheless, the problem with the crash message and that it might as well cause something ELSE to be shot down when Firefox could just unload a tab remains.
|
||
Updated•2 years ago
|
Description
•