This is how Mozilla's own updater works (if you use the .tar.gz version), but the distro package updater just overwrites everything without waiting and applications like Firefox have no control over that. As a user, you'd really want to disable unattended updates for such software.

It's not an issue for these .deb packages because they enable the (experimental) forkserver.

What determines "excessive"? In this case it's for a security feature that Chrome lacks(!).

Did you report this on Bugzilla? Even if it's not Firefox's fault if you don't report it no-one knows about the issue.

Recent versions of Firefox allow you to block some stuff like that: https://support.mozilla.org/en-US/kb/identify-problems-third...

Though it's possible they use different code injection tricks to make blocking impossible. (You can't block Defender from listening to events for example)

One reason why it shipped on Windows first is that the situation is more serious there. The article goes into details why the different overcommit behavior is more problematic on Windows, and you're more likely to OOM there as a result.

Getting macOS to OOM is actually pretty difficult, we probably want to unload tabs before that point for performance (swap!) reasons, but that's also harder to measure very reliably.

Because for some people their open sites, and the ability to switch quickly between them, is the most important use of their machine and what they want their RAM to be used for.

It wasn't enabled by default because it didn't work well enough. Getting better low memory triggers was a key to making this an overall benefit, and not just a user annoyance.

>very rarely Firefox would crash

The feature stops (or reduces the likelyhood) of that happening. It literally is made to trigger in a situation where the alternative is to crash.

>So, if I want to disable this, I should set a big number to the browser.low_commit_space_threshold_mb pref in about:config, right?

This will ensure that you crash and have to reload all of your tabs instead of the oldest ones, yes :-)

>though it's not clear to me what the difference is

This one works well enough that we can default it on :-)

The previous one didn't reliably detect low memory situations and you could crash with OOM before it ever triggered. The article goes into detail about the various signals that have to be monitored on Windows. We had to do some work on gathering the metrics and correlating with crash data to determine when to trigger.

That's definitely something we would want to do, but it requires a (very) reliable measurement method for this kind of memory pressure.

If it's not reliable, the browser unloads tabs when it's not needed, and that's way more annoying.

>No thanks, I'd rather get more RAM or swap space for paging.

As the article explains, if you have enough swap you'll never trigger this. It activates right before you'd have crashed otherwise.