Quantum wasn't even about Chrome compatibility. The XUL extension mechanism was permanent technical debt loaded onto the browser because of how it exposed features, basically welding things directly onto the browser's guts, which on the one hand is super-convenient for making radical changes in an extension and on the other hand is a nightmare to maintain.
The analogy I've used is the Amiga operating system design versus Unix when it comes to multi-core / multi-processor versus multiprocessing. Amiga welds everything to the hardware, the Unix design has a "system call" mechanism cleanly separating your programs from the OS and vice versa.
Because Unix has this relatively thick layer between the OS kernel and the rest of the world, you can just pick up your entire kernel, wrap it in a lock (in Linux this was called the Big Kernel Lock in some BSDs it was Giant Lock and other Unix systems gave it different names) and you've got a multi-processor capable system. Linux did this in about a year IIRC. For purely CPU bound software this minimal work gets you 99.9% of the performance of a custom built OS designed from the outset for multiple processors. Subsequent work to get rid of the BKL further improves performance on more sophisticated workloads, but you're off to a great start.
Amiga couldn't do that, every part of their system could interact with every other part as it liked, so if you tried to just add one lock to protect things the resulting system might randomly deadlock, maybe only on systems with specific hardware or software combinations, and you basically needed to reconsider everything from the ground up.
You need a degree of abstraction like this, the Chromium-style web extensions have it, the XUL extensions didn't, adding it to the latter would have been years of work only to deliberately be incompatible with both existing software on Firefox AND everybody else, madness.
There are definitely things we want in extensions. For example Firefox has a copy of the Public Suffix List baked inside it (all browsers should have this, in its absence you'll get weird security behaviour around how domains and sub-domains work) and I'd like to access their copy from inside an extension to make it behave how users expect. But obviously the extension can just ship its own copy of the PSL, and then keep that up-to-date it's just a waste of resources.
> The XUL extension mechanism was permanent technical debt loaded onto the browser because of how it exposed features, basically welding things directly onto the browser's guts, which is a nightmare to maintain.
There is no evidence for this at all. Extensions can't modify the rendering engine.
"guts" meant the XUL implementing the Firefox UI. tialaramex is absolutely right about that, extensions had total access to that XUL/JS state, which is why changes to the Firefox UI inevitably broke extensions.
The analogy I've used is the Amiga operating system design versus Unix when it comes to multi-core / multi-processor versus multiprocessing. Amiga welds everything to the hardware, the Unix design has a "system call" mechanism cleanly separating your programs from the OS and vice versa.
Because Unix has this relatively thick layer between the OS kernel and the rest of the world, you can just pick up your entire kernel, wrap it in a lock (in Linux this was called the Big Kernel Lock in some BSDs it was Giant Lock and other Unix systems gave it different names) and you've got a multi-processor capable system. Linux did this in about a year IIRC. For purely CPU bound software this minimal work gets you 99.9% of the performance of a custom built OS designed from the outset for multiple processors. Subsequent work to get rid of the BKL further improves performance on more sophisticated workloads, but you're off to a great start.
Amiga couldn't do that, every part of their system could interact with every other part as it liked, so if you tried to just add one lock to protect things the resulting system might randomly deadlock, maybe only on systems with specific hardware or software combinations, and you basically needed to reconsider everything from the ground up.
You need a degree of abstraction like this, the Chromium-style web extensions have it, the XUL extensions didn't, adding it to the latter would have been years of work only to deliberately be incompatible with both existing software on Firefox AND everybody else, madness.
There are definitely things we want in extensions. For example Firefox has a copy of the Public Suffix List baked inside it (all browsers should have this, in its absence you'll get weird security behaviour around how domains and sub-domains work) and I'd like to access their copy from inside an extension to make it behave how users expect. But obviously the extension can just ship its own copy of the PSL, and then keep that up-to-date it's just a waste of resources.