gcp

Any memory allocation failing within the browser forces an instant crash unless the callsite explicitly opts in to handling the allocation failure.

"Check malloc failure" is an opt-out feature in browsers, not opt-in. It's the same in Chromium. Failing to check would cause too many security issues. (One more reason new stuff tends to prefer Rust, etc)

Not sure if it's a coding issue in the Firefox version of Dark Reader, or it's hitting some slow path in Firefox itself.

Or missing out on new anti-fingerprinting and anti-tracking improvements. Note that adblockers don't generally do the former.

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

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)

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.

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 :-)

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.

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

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

Firefox should literally never crash. If it does, that's a serious bug (but especially on Windows, not necessarily in Firefox itself).

Firefox should literally never crash. If it does, that's a serious bug (but especially on Windows, not necessarily in Firefox itself).

I have no idea why you think that random HN discussion afterwards (in response to an article filled with misinformation!) would have any bearing on how Firefox is developed.

https://www.mozilla.org/en-US/about/governance/

>Is there a link to discussion?

There's been about 1.5 year of extended discussion and iteration over DoH, yes. I'm sorry but there certainly isn't just a "single" link!

Quite an important detail.

The conclusion of the debate was that it vastly improves the privacy for most users. Which is why it shipped in Firefox.

Take that into account when you read (misleading, factually wrong) push-back like the original article.

That's just what "The Machine" says and may not be the intended policy, even if it is now the effective one.

In reality, "they" couldn't even ship Array.prototype.flatten because a few sites won't update MooTools. What you describe couldn't be further removed from reality.

https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

"GA also doesn't track IPs or store PII within the tool."

Data portability and such are likely a much bigger hassle. Those are actual features you need to implement now if you stored PII.