gcp

I don't think Firefox has the access permissions needed to read MCE status, and the vast majority of our users don't have ECC, let alone they're going to run memtest86(+) after a Firefox crash.

If they did, we wouldn't be having this discussion to begin with!

No.

Deduplicating and identifying the source of a crash point is surprisingly hard, to the point that “it’s the only crash of its kind” could be a bug in your logic for linking issues.

This is a bit vague to really reply to very specifically, but yes, this is hard. Which is why quite some people work in this area. It's rather valuable to do so at Firefox-scale.

Even if the majority of time it generates the “same” failure mode, it can still sporadically generate a rare execution trace.

This doesn't matter that much because the "same" failure mode already allows you to see the bug and fix it.

Did you actually read the posts that started this topic, or are you being an ass for no reason?

Hint: No-one is claiming memory is to blame for 100% of the Firefox crashes. No-one is claiming it's 99% either.

I'm quite confident to say that millions of people use Firefox to comment on Reddit or similar sites every day, or write long posts, without seeing this problem.

Without knowing more about your configuration, it's hard to give advice, but definitely worth trying with a clean profile first.

If you don't report this problem upstream it will never get fixed, as obviously no-one else is seeing this. Firefox has a built-in profiler that you can use to report performance problems like this.

You were seeing issues from the graphics driver, not Firefox.

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)

Yeah, Dark Reader is known to totally plummet Firefox performance.

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.

It helps if you file bugs in Bugzilla. You can link to them here, there's a good chance a developer will find them.

Change tends to mean things like exciting new spying and UI regressions

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

The whole point of the about:restartrequired warning is to avoid this problem. If you're crashing, I hope you've been filing bugs.

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.

People on low memory machines, or people on big boxes that read some article about how swap makes your SSD die and tried to disable Windows swapping (or downloaded some "optimization" tool that does that). The last is explicitly hinted in the article. There's a surprising amount of people in that situation.

The original ticket seems to indicate this is a leak in a Windows accessibility service and so far there was no luck in finding a way to avoid it. That sucks.

Paste a few links from about:crashes here. If you click on them, you might find the associated bug (if it exists).

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

Paste a few links from about:crashes here. If you click on them, you might find the associated bug (if it exists).

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

it looks like HN folks are not in favour of these integrations, including me.

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!

...users in the US.

Quite an important detail.

First announcements were even longer ago: https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...

This has been tested and debated for months. Initial support for Firefox rolled out 9 months ago or so: https://miketabor.com/enable-dns-over-https-and-encrypted-sn...

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.

So the machine "fixed" the "glitch"?

YouTube is requiring them to switch to monetized

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