Shared publicly  - 
Reading some of the comments on the Blink launch, I've noted a little confusion over the relative roles of WebKit/WebKit2/Chromium code modules.

WebCore is the actual layout engine. My understanding is that it's not intended to be consumed by people directly.
WebKit provides an embedding API around WebCore. Different ports provided different implementations for various UI frameworks like Cocoa, Gtk, etc.
WebKit2 is similar, but using a multi-process harness.

For Chrome, we provided our own implementation of the WebKit API intended to be used by only one customer - our Content API layer which is the real embedding API that the rest of Chrome is built on. It provides some level of isolation from WebKit/Core for the rest of the Chrome codebase. All of our ports are done in the Content layer, since WebCore is run in a separate process with limited privileges (these processes can't even create a platform native widget). Content layer provides the native widget onto which the rendering engine can draw, the bridge to the native event system, networking, and other necessary pieces.

Content does not provide a stable API - it's primary purpose is to support the development of the Chrome browser. It changes quite a lot, so to use it you either need to develop in lockstep with it at tip-of-tree like Chrome does, or use a third party solution like CEF (Chromium Embedded Framework [1]) which wraps Content in a more stable API.

Note that Content predates WebKit2 by several years, it was one of the first pieces of code developed for Chrome and has grown significantly since. Content is a foundational piece of the architecture of Chrome, and much of our application code is built on its behavior and abstractions.

A multi-process architecture for a browser is a complex and nuanced thing. One example, in a cross platform world when you're supporting NPAPI plugins, you end up having to support native UI framework quirks and possible deadlocks that are very platform specific (I'm looking at you, Win32). The Chrome team has spent a huge amount of time over the past ~ half decade hunting down this kind of nastiness.

For these reasons, just "replacing" Content with another upstream library (e.g. WebKit2) designed with potentially different constraints in mind without understanding its behavior would be a major undertaking.

Justin Schuh's profile photoHussein Qusiere's profile photo
I've had a hard time explaining to people why we couldn't just adopt WebKit2, because they see things like multi-process or sandboxing as equivalent features. But the fact is that switching to WebKit2 would not only have been a massive amount of work. It's that the result would be much worse from a security perspective, because we'd need to emulate Safari's far more permissive seatbelt-based architecture on all other platforms. It would also prevent us from ever implementing something like site isolation <>, which simply isn't possible given how WebKit2 splits its network layer and processes.
Add a comment...