Home > Free Software, Igalia, WebKit > WebKitGTK+ 2.2.0: It shines and doesn’t blink

WebKitGTK+ 2.2.0: It shines and doesn’t blink

With a bit of delay but we have finally released a new stable version of WebKitGTK+. This is the first stable release after the major 2.0 release. It mainly contains a lot of bug fixes and a few important new futures and API additions.

New Web Inspector

WebKitGTK+ now uses the new Web Inspector recently opensourced and upstreamed by Apple. We took advantage of the migration to improve the way inspector resources are distributed by compiling them in the WebKitGTK+ library as GResources. This means that resources are now always available without having to run make install or set environment variables.

WebKitGTK+ new Web Inspector

Initial Wayland support

WebKitGTK+ 2.2 can be built with Wayland target if it’s available (it requires GTK+ 3.10 compiled with Wayland support). Not everything is fully supported yet, but the WebKit layout tests can be run under the Weston compositor and WebGL content works under Wayland displays too. There’s more detailed information in Žan Doberšek’s blog.

Video accelerated compositing support

When accelerated compositing is enabled, the GStreamer media player can play videos using OpenGL. You can find more details in Víctor’s blog.

Custom JavaScript injection

This was one of the major regressions in WebKit2GTK+ compared to the WebKit1 API. WebKitGTK+ 2.2 now allows to inject custom JavaScript code using the JavaScriptCore C API from a WebKit Web Process Extension. New API has been added to also allow running specific JavaScript code in isolated worlds. You can find examples about how to use this API and how to write Web Process Extensions in general in this post.

Improved accessibility support in WebKit2

Accessibility support in WebKit2 has been reworked to not depend on pango and gail, which resulted in several bugs fixed and a much better accessibility support. Check Mario’s blog for all the details.

New API

Categories: Free Software, Igalia, WebKit Tags:
  1. malaclypse
    September 27th, 2013 at 15:35 | #1

    Qt recently announced that they are planning to switch from WebKit to Chromium (probably Blink and V8): http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/ . Will this have consequences for WebKitGTK?

  2. Kurt Kugel
    September 27th, 2013 at 21:09 | #2

    @malaclypse
    I hope not. Qt integration of Chromium is horrible. For example it cannot use native scrollbars.

  3. carlos garcia campos
    September 28th, 2013 at 08:24 | #3

    @malaclypse
    Well, it’s true that in WebKit2 Qt, EFL and GTK+ ports share more code, so there’s been more cooperation between ports, and all WebKit ports contribute to WebCore in some way, but in general I don’t think it will have a huge impact for WebKitGTK+.

  4. Kẏra
    September 28th, 2013 at 09:51 | #4

    What about sandboxing and crash control?

  5. carlos garcia campos
    September 28th, 2013 at 11:57 | #5

    Kẏra :
    What about sandboxing and crash control?

    Sandboxing is still in our RoadMap and there’s already a patch in WebKit bugzilla (See https://bugs.webkit.org/show_bug.cgi?id=110014), so hopefully it will be finished for 2.4. Regarding crash control, we already support it, there’s a signal emitted when the web process crashes, and then you can just start a new load and a new web process is spawned automatically.

  6. Josef
    September 29th, 2013 at 15:32 | #6

    @Kurt Kugel
    They dont even ship the chromium port yet?

  7. Marcel
    October 5th, 2013 at 23:23 | #7

    I created a minimal WebExtension in vala. (Only the initialize method is called). Now it seems that all the classes for WebExtensions like WebPage / WebFrame are not exposed through GObjectIntrospection. Is there a way to programm a WebExtension in vala?

  8. carlos garcia campos
    October 6th, 2013 at 12:05 | #8

    @Marcel
    hmm, good point, it seems we are not generating introspection for the extensions API. Could you please file a bug report in bugs.webkit.org?

  9. Marcel
    October 6th, 2013 at 14:00 | #9

    @carlos garcia campos

    I created the bug-report: https://bugs.webkit.org/show_bug.cgi?id=122407

    But I’m still wondering if its possible to create an extension in vala, even with the introspection available.

    It seems that vala is doing some magic with method names to get the OO mechanics working but webkit expects a certain function name (webkit_web_extension_initialize) to be present.

  10. carlos garcia campos
    October 7th, 2013 at 08:47 | #10

    @Marcel
    As long as you can provide a shared library containing webkit_web_extension_initialize as a public symbol. I don’t know vala enough, so I don’t know. Can’t you write the entry point in C and the rest in vala? Everything will be C in the end once the vala code is compiled into GObject.

  11. Marcel
    October 7th, 2013 at 19:17 | #11

    @carlos garcia campos

    This could be an idea. Thanks for sharing :-)

  1. No trackbacks yet.
*