I won't speculate on why people make the technology decisions they do - and in this case I'm somewhat distant from the WebKit team.

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.

Opera is planning to use this, for example.

Yes, but only in the sense that Opera is evolving into a new brand of Chromium. Opera isn't a relevant factor in the technology discussion anymore.

> 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.

Out of curiosity, is any of the chrome process isolation going to be going upstream to webkit or augment webkit2 isolation?

It would be pretty ironic if Apple were actually annoyed that Chrome was developed in secret considering they forked KHTML and developed it into Safari & WebKit in secret in essentially the same way.