In my personal opinion, while the flexibility of the old XUL addons was amazing, the two big issues are compatibility and performance.
Compatibility: these addons could be broken very easily because they could depend on almost anything, and with the monthly release cycle, it is very difficult for mod authors to keep up. For instance, some addons would work by taking a core browser function written in JS, convert it to a string, run a regular expression to edit the string, then use eval to create a new function to replace the old one. In some release, the syntax of the "convert a function to a string" output changed slightly and it broke these addons, because it broke the regexp they were using.
Performance: XUL addons could do all sorts of things that are horrible for performance, and there was no real way for a user to tell what was causing it, because the addon wasn't isolated in any way. I ran into somebody who was having severe performance issues because the browser was generating colossal amounts of garbage for no reason. It eventually turned out that on a whim they'd installed a "LaTeX the World" addon, which would look for LaTeX typesetting instructions on pages and replace it with the nice looking output. The problem was, the way it worked was that every 10 seconds or so it would convert the entire contents of every single tab you had open into a zillion strings, search those strings, then throw them out.
rlbox is used for more than one library: "Now, we’re bringing that technology to all supported Firefox platforms (desktop and mobile), and isolating five different modules: Graphite, Hunspell, Ogg, Expat and Woff2"
Their concern is not with theoretical vulnerabilities, but actual ones that are being exploited. If an attacker never tries to find a vulnerability in some code, then it might as well not have it.
Firefox uses unified builds, where a bunch of .cpp files are globbed together and compiled at once. That helps a lot, but a build still takes a bit of time unless you are on an absurdly fast machine. Chrome used to also support this, called "jumbo builds", but they didn't want to deal with the maintenance overhead. Presumably all of the Chrome developers employed by Google are using some kind of massive distributed build infrastructure so there's little impact of slower builds on individual developer productivity, so the use case of building on a single computer is not as prioritized.
Which is easy money that Apple uses for the company as a whole. They don’t make Safari because of Google’s money nor is it likely they would stop developing it if that money was no longer paid.
reply