Yes, we did it again, we have just released WebKitGTK+ 2.4.0, another major stable release with a lot of bug fixes, some new features and more complete API.
Multiple Web Processes
This is the most important new feature included in this release, and the one we have spent most of the release cycle with. All started during the WebKitGTK+ hackfest when a team of around 10 people worked together to implement the base of the multi-process support. And at the very end of the release cycle we have been able to turn it on by default in Epiphany.
DOM touch events support
WebKitWebView now processes the touch events happening in the widget to notify the DOM, making modern websites using DOM touch API properly work. Carlos Garnacho has taken a screencast to show it in action
Plugins cache
When the first page containing plugins was loaded, the UI process got blocked for some time, while the plugins were scanned. This was one of the most annoying bugs of WebKitGTK+ introduced in 2.0. Plugins are synchronously scanned on demand during the page load, and it’s something that can’t be avoided. WebKitGTK+ 2.4 uses a persistent cache to store information about all plugins, so that plugins are only scanned the first time or when they change.
New API
- Process model: webkit_web_context_set_process_model() allows to set the WebKitProcessModel used by the WebContext. The only thing you need to do to have multi web process support in your application is calling webkit_web_context_set_process_model() with WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES. Applications can implement other multi web process models based on this one using webkit_web_view_new_with_related_view() to create a web view in the same web process of another one.
- API to pass initialization data to the web extensions: We can pass initialization data using a GVariant from the UI process to the web extension. A new signal WebKitWebContext::initialize-web-extensions has been added to notify about the best moment to use any API that needs to be called before the web extensions are loaded. The new function webkit_web_context_set_web_extensions_initialization_user_data() allows you to set a GVariant that will be passed to the web extension. In the web process side the new initialization function webkit_web_extension_initialize_with_user_data() can be used to receive the GVariant as parameter. This way we don’t need to use ugly hacks like the environment variables we had in Epiphany.
- TLS errors API: When the TLS errors policy set is WEBKIT_TLS_ERRORS_POLICY_FAIL and a website fails to load due to TLS errors, the new signal WebKitWebView::load-failed-with-tls-errors is emitted passing a WebKitCertificateInfo to the user. The load is always finished, but now it’s possible to add an exception of the given certificate for a host with webkit_web_context_allow_tls_certificate_for_host() and start a new load.
As always a huge thanks to all the contributors that make this possible, and very specially in this release to the sponsors of the WebKitGTK+ hackfest 2013 (Igalia and the GNOME Foundation).
WebKit1 deprecation
There’s one last thing I would like to mention. Even when WebKit1 API has been deprecated since we released WebKitGTK+ 2.0, we have kept shipping both APIs in our tarball releases. A decision hasn’t been made yet, but this is probably the last release including the WebKit1 API, we have plans to remove the WebKit1 code from trunk and move all the build bots to run only WebKit2 tests. We encourage everybody to port their applications to WebKit2, submitting bug reports if there’s anything preventing the switch, and of course we are happy to help on IRC, mailing list, etc.