It seems like the HN submission form truncated the # from the end of the URL I linked to, which linked to the relevant comment. I'll try that here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c82
and
I think its a growing issue, as they mature/migrate their older code base, issues become less frequent.
- require admin rights (which means that if they have vulnerabilities, it can take control of the entire machine, even if Firefox itself is sanboxed);
- monkey-patch the Firefox executable in memory, which works (when it does) as long as the version of the software tracks closely the version of Firefox, which may or may not be the case;
- ... and also decreases the memory-safety of Firefox, which makes it easier to pwn;
- ... and also makes the crash reports unreliable;
- install encryption certificates that are actually less trustworthy than Mozilla's, hence decreasing the security of https;
- block Firefox and add-on security updates, also decreasing security;
- install privileged add-ons, many of which are easy to exploit from any webpage;
- ...
Part of the work on Crash Scene Investigations was attempting to determine whether the crash was in Firefox or in code or in some bogus foreign code. Depressingly often, it was the latter.
In your case, it's entirely possible that malwarebytes was simply untested on Firefox.
Given that in many industries insurances and, in some cases like banking, the law requires companies to monitor HTTPS traffic of browsers for compliance, it might be better if browsers had a dedicated filter / monitor API.