We've been there with CSS box model, DOM levels, (X)HTML(5), and CSS prefixes. There have been some cases of cooperation, e.g. SHA-1 certs and kicking of bad CAs, but most of the time browser vendors only "break" things gradually and only when it affects < 0.1%.
Other examples:
Content-Type. There were a few years where many sites were misconfigured to serve virtually every non-HTML file as text/plain. IE, deviating from the HTTP spec, always used its own algorithm to detect the actual file type and thus "worked", whereas Netscape (and later Mozilla) respected the header and would display "garbage".
Windows-1252 mojibake. Various Windows-based authoring tools simply used the native Windows code page 1252 to encode their text in HTML files, which were then claimed to be encoded as ASCII or ISO 8859-1. This led to documents that mostly looked correct but would have garbage sprinkled around due to added punctuation in Windows-1252 (primarily the distinct open/close quotes and em-dashes, if memory serves). IE of course handled these "correctly", i.e. interpreted ASCII or ISO 8859-1 to mean Windows-1252. I think this behavior is now specified by HTML5 under certain conditions.
You can leave out "under certain conditions", whatwg just plain specifies the "iso-8859-1" label identifies the windows-1252 encoding [1]
Middleboxes are considerably more problematic, since you've got a lot of manufacturers out there, some of them might actually be out of business. Pushing firmware upgrades to all of those middleboxes would also be a nightmare. And the icing on the cake is actually finding the malfunctioning middleboxes, since they can be anywhere between the end user and the web server.
No. Every website that uses a Symantec cert (that was issued before 2017-12-01) needs to renew their cert early to move to their new root.
Anyway, https://ftp.mozilla.org/pub/firefox/releases/ has links to all the Firefox release binaries and corresponding source snapshots starting with version 0.8. It includes a number of the betas as well (so for example has the Firefox 58 beta builds already).
I wonder how long and difficult it must be to get all the required dependencies to compile a modern web browser...
[two hours of obscure error messages later]
"You have v2.3030392.302 of dependency 113, you need to compile v2.3030392.300 in 32-bit first, then build the 64-bit version of v2.3030392.301 then ..."
You get all the compiler errors fixed and then it's on to round two... linker errors.
I could definitely see someone doing that with Firefox. They may already exist. I've just, from experience, had so much trouble with compiling large codebases.
On the bright side, the larger a codebase, often, the more popular. And the more popular, the more likely people will have EXACT dependencies listed.
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... lists the actual set of libraries and whatnot needed; converting those to the relevant package names for the Linux distro of your choice is tedious, but not too hard.
For an old version, things could be more complicated, depending...
That said, I wish we would be more willing to force these rusted joints to open, breakage be damned. Breaking 3% of the web sounds like a lot, but it's not that much, especially considering that anyone broken will very quickly upgrade.
By using elaborate workarounds described in the article, we recognize and reward the worst technical practices. The author may not want to cast blame, but I do.