By Martin Robinson.
After two years of work, WebKit2 has arrived to the GNOME platform, bringing security, stability, and performance. This talk will outline the new design and dive briefly into some of the gory technical details. Also, included will be a mountain of practical advice for application developers about the transition, such as whether or not applications should be rewritten for WebKit2 and how best to take advantage of the new multi-process model.
4. WebKit
· Web content engine
· Processes and renders web content
· Started as a fork of KTHML and KJS
· Open source since 2005
· Goals: open source, compatibility, compliance, stability, performance,
security, portability, usability, hackability
· Non-goals: being a full web browser, being a science project, having
reusable components, unlimited scope
· Split into ports: GTK+, Qt, EFL, Mac, Windows
4/29
5. WebKitGTK+
· Each WebKit port is composed of
- Platform interfaces
- API layer
· WebKitGTK+ platform layer:
- libsoup for networking
- cairo for rasterization
- OpenGL for making the scene graph and WebGL
- GStreamer for media
- Various GTK+ APIs for talking with the system
· API layer is a GtkWidget and a set of GObject APIs
· WebKitGTK+ is used by Epiphany, Midori, yelp, devhelp
5/29
7. Minor Philosophical Point
· Code has bugs that crash the program.
· Code has bugs that allow arbitrary code execution.
· Code relies on dependencies with bugs.
· Code handles fonts and images that are essentially small programs.
· WebKit2 is a pragmatic response
7/29
8. Why WebKit2?
·
·
·
·
The web platform is huge
Make crashes less inconvenient for users
Prevent bugs and crashes from exposing user data
Prevent bugs and crashes from damaging the system or executing
arbitrary code
· Stop web applications from blocking each other
8/29
9. WebKit2
· Give the web rendering parts of WebKit their own process
· Page crashes don't crash the browser
· Can put vulnerable data into a separate address space
· Sandbox web rendering
· Prevent pages from accessing the disk and operating system
interface
9/29
12. IPC
· IPC glues the different processes together
· Three types of IPC in use in Webkit
- Messaging: Unix domain socket for sending messages
synchronously or asynchronously
- Shared memory: shmem for passing large messages and bitmaps
- Shared surfaces: XComposite/XDamage for passing hardware
accelerated surfaces cheaply
12/29
13. Accelerated Compositing
· WebKit has its own hardware-accelerated scene graph of page content
- Prevent unnecessary redraw
- 3D CSS transforms
- WebGL
· Scene graph is in the WebProcess, but drawing happens in the
UIProcess
· XComposite/XDamage allows compositing and final paint in different
processes
13/29
16. Why Port?
· WebKit1 development has moved to maintenance mode
· WebKit1 will be deprecated in the future
· The WebKit2GTK+ API is richer and better tested
· Porting to WebKit2 brings immediate performance, security, and
stability benefits
16/29
17. Porting Challenges
· There is not yet a porting guide
- Extensive API documentation
· Many synchronous APIs with return values are now asynchronous
void webkit_web_view_save (WebKitWebView *web_view,
WebKitSaveMode save_mode,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data);
C
· Two-way communication from the page is more complicated
- Injected script source
- Custom protocols
- GObject DOM bindings
- Page access via the JSC API
17/29
18. Injected Script Source
· Strings of JavaScript source code executed asynchronously in the
WebProces
· Can return a value which is serialized and sent across the IPC
messaging channel
18/29
20. Custom Protocols
· Page to WebKit communication by accessing a resourcess across a
custom protocol
· Example of this approach are about: pages
· Communicate without reloading the page via AJAX
· Subject to same-origin security restrictions
20/29
22. Web Extensions
· Web extensions are shared objects that execute in the WebProcess
· No IPC penalties
- Synchronous behavior does not block the UI
- Direct access to page state including the DOM
- Timing is less of an issue
· Written on top of the port-independent WebKit InjectedBundle
· No IPC API, but you can use DBus for communication with the
UIProcess
22/29
23. Web Extensions
C
void
webkit_web_extension_initialize (WebKitWebExtension *extension)
{
printf ("Hello from a WebProcessn");
}
$ gcc -c -Wall -Werror -fpic web-extension.c
$ gcc -shared -o web-extension.so web-extension.o
SHELL
webkit_web_context_set_web_extensions_directory (webkit_web_context_get_default (),
"/path/to/shared-object");
C
23/29
24. GObject DOM Bindings via Web Extensions
· GObject DOM bindings allow accessing page DOM using GObject APIs
· Cannot run in the UIProcess, the DOM is in a different address space
· In WebKit2, these are only accessible via Web Extensions
static void
document_loaded_callback (WebKitWebPage *page, gpointer user_data)
{
printf ("title: %sn", webkit_dom_document_get_title (webkit_web_page_get_dom_document (page)));
}
C
static void
page_created_callback (WebKitWebExtension *extension, WebKitWebPage *page, gpointer user_data)
{
g_signal_connect (page, "document-loaded", G_CALLBACK(document_loaded_callback), 0);
}
void
webkit_web_extension_initialize (WebKitWebExtension *extension)
{
g_signal_connect (extension, "page-created", G_CALLBACK(page_created_callback), NULL);
}
24/29
25. Injected JavaScript via Web Extensions
· Similar to the GObject DOM bindings approach
· Instead of using the GObject API, use the JSC C API
· Can interact with the page as well as insert JavaScript objects backed
by native code
· The most flexible approach
· Necessary Web Extension API should appear soon in a future release
25/29
28. WebKit2
· Multiple WebProcesses
- Isolate applications from each other as well as from the UI
- Prevents crash from crashing every tab
· Networking Process
- Necessary for multiple web processes
- Avoids complexity of caches/databases with multiple writers
· Offline Storage Process
· Disk access blocking and insecure
· More easily sandbox WebProcesses
28/29