Hacking on Blink and Chromium

This blog documents my attempts to use and improve the Web platform

Blink: Chromium's Rendering Engine

Blink is Google’s fork of the WebKit browser engine, which in turn is Apple’s fork of KDE’s KHTML engine.

WebKit Legacy

WebKit (the precursor of Blink) was designed to be platform-independent, and was successfully ported to many platforms, such as Mac OS and iOS (using Cocoa), Windows, Linux (using GTK), and Android. Chromium was also designed to be ported to multiple platforms, and adds another platform-independent layer on top of the Blink rendering engine, called the content module. So, from the WebKit code perspective, Blink sits on top of a single platform, called “chromium”.

The WebKit project contains a rendering engine (WebCore), a JavaScript engine (JavaScriptCore), and an embedding layer. Blink adopted WebCore, but uses the V8 JavaScript Engine instead of JavaScriptCore, and dropped the embedding layer in favor of having its content layer talk directly to WebCore.

Code Layout

Blink’s source code is at third_party/WebKit in the Chromium source tree. The top-level directories are as follows.

  • public/ contains the header files makeing up the API between Blink and Chromium’s content layer.
  • Source contains the actual Blink source code.
  • LayoutTests has automated tests for the engine’s features.
  • Tools contains scripts for building and running the code. Tools/Scripts is heavily referenced in WebKit’s old

I have not explored the PerformanceTests or ManualTests directories. They appear to be described by the WebKit Wiki’s Performance Tests page and WebKit Wiki’s Manual Testing page.

At the time of this writing, WebKit’s source tree has the same top-level structure. Comparing the Source/ directories shows the top-level differences between Blink and WebKit.

The Public API

The headers in public/ are relatively well-commented, so they make a great starting point for understanding a part of Chromium.

The public APIs fall into two big categories.

  • public/web contains the API implemented by Blink and called by Chromium’s content layer
  • public/platform has the lower-level API used by Blink and implemented by the content layer

The classes in the public APIs usually have easy-to-guess corresponding classes in the implementation. For example, the WebView abstract class, defined in public/web/WebView.h, has one concrete implementation, WebViewImpl, which is defined in Source/web/WebViewImpl.h. Source/web/WebViewImpl.cpp contains both the WebViewImpl implementation, as well as the definitions for WebView’s static members.

The Source Code

Blink’s implementation is split into the following top-level directories.

The Layout Tests

Blink’s regression tests are Web pages that are loaded in a content layer that is hacked to output textual representations of the pages. This is really convenient, because a Web application developer can contribute a failing test for a bug or feature without having to learn C++ or Blink’s inner workings.

To get a taste of what tests look like, skim LayoutTests/fast/xmlhttprequest-get.xhtml and the corresponding LayoutTests/fast/xmlhttprequest-get-expected.txt.

Building and Testing

The all_webkit target contains the Blink-related deliverables.

ninja -C out/Debug blink_tests

Blink cannot run on its own, due to its dependency on Chromium’s content layer. The Content Shell offers a rudimentary UI on top of the content layer, and is a low-overhead way of getting Blink up and running.

# Linux
out/Debug/content_shell
# OS X
out/Debug/Content\ Shell.app/Contents/MacOS/Content\ Shell

Further Reading

At the time of this writing, the Technical Articles in the WebKit blog and many of the entries on the WebKit Wiki are still relevant and worth the time spent reading them.

References

Comments