In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.
That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
[1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org
Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is.
A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app.
One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.
Please do! I would love to read that.
"The mechanism is based on a relatively dated concept, superseded by compile-time code validation techniques such as Google's own Native Client"
so I don't think that's what the article meant.
I think addons are a small part of the picture.
The big deal is there are only so many Firefox developers, and Electrolysis was turning into a real sinkhole of time with no end in sight. There were a lot better ways to make Firefox a better browser in the meantime, and those things are being done.
Firefox on Android used to use Electrolysis until it switched to the current Java front-end. And FirefoxOS is using it for sure: process per app, so that apps can be easily killed in low-memory conditions.
As for "legacy add-ons", that would be "every single add-on". Not to mention that the desktop Firefox UI itself would have to be heavily rewritten as well. The judgement, as mcpherinm says, was that the cost was too high for the possible gains. I agree that process isolation is good for security, but there are various other security mitigation strategies that can be used that had a higher bang for the buck at the time.
If there's actually high costs, it shouldn't be due to a "antiquated" multi-process architecture, but other things like marshalling data to and from the JS engine.
Either this is hyperbole, or it means the author is aware of research or a technology that the tech mainstream is unaware of.
This is how science works: research suggests some result; until other research suggests a different result, the first result is our best working hypothesis. Process isolation is hardly antiquated.
As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.