A group of core WebKitGTK+ hackers and contributors will meet at the Igalia offices in A Coruña, and we’ll hack for a week on things like GObject DOM bindings, libsoup, a harfbuzz backend, native theming through offscreen widgets, HTML5 video/audio support and many more things.

I’ve put up a wiki page with all the information we have so far, so keep an eye on it if you are interested. Also, we have two sponsors so far, Collabora and Igalia (thanks!), but we can always use a few more of them. If you feel like you could contribute to advance the state of the Web support in our platform, please drop me a line at my email address, xan gnome org, or contact the GNOME foundation directly.

Happy hacking!

So, we made it in time for the release. After months of hard work 2.28 is out, and hopefully it will hit a repository near you (in case you are not so much into hunting projects in their natural habitat). Some reviews think Ephy/WebKit is not too bad and appreciate the effort we are putting into bringing WebKit into the platform, so I guess we can be happy of our progress so far.

Speaking of WebKit, we branched for our semi-stable 1.1.15 release. After some talks we decided to not declare our APIs stable yet, since the development is still advancing very fast and we could use a full cycle of testing to see what works and what doesn’t, but nevertheless we will support 1.1.15.x as a stable release in every other aspect: no new features, only bugfixes and patches for security issues, supported until the next stable release is out. It’s the recommended companion for GNOME 2.28, so distro guys you know what to do! And, just to see if anyone was paying attention, we quickly rolled a 1.1.15.1 with a couple of important bugfixes; you can get it at the usual place.

2.30 – The Future

But enough talk about the past, what will the future bring?  These are some of the things that we plan to do, or at least get started, for 2.30.

GObject DOM bindings

WebKitGTK+ already provides APIs to do most of the things applications need to do when dealing with Web widgets, with one very big exception: access to the DOM. DOM manipulation has to be done, as of today, through sad APIs like webkit_web_view_execute_script, which make doing anything other than trivial things pretty cumbersome and difficult to debug. Wouldn’t it be nice to be able to access the page contents through nice GObject APIs, with bindings for all languages through gobject-introspection? Yes, it would, and it clearly is what we are missing to be able to create a new kind of GNOME applications. Other ports, like Mac or Qt, already provide something like this, so clearly we have to step up to this challenge Expect to see, at least, basic GObject DOM bindings for WebKitGTK+ in time for GNOME 2.30.

GNOME shell integration

An idea that has been floating in my head since GCDS is to try to integrate Epiphany more closely in the coming brave new world of GNOME Shell. I think our UI can be kept simple and usable and at the same time updated to use all that crap the chip manufacturers have been putting into your computer for the past 10 years, so we should give that a shot. I’ll be attending the Boston Summit to see what I can do about this being among all the Shell gang, and rumour has it Gustavo is already doing some crazy experiments with Clutter and Epiphany.

Accessibility

When WebKitGTK+ was accepted for 2.28 the Release Team expressed their trust in that we’d continue our work improving the a11y support in the engine. Me and Igalia will keep our commitment to see this happen, and with 2.28 behind us I’m already looking into it again. Also, I’ll finally meet Joanmarie during the Boston Summit, which I’m sure will be serve to make things move faster and better.

HarfBuzz font backend

Behdad speaks, and we listen. In his own words the Pango backends in WebKitGTK+ and Gecko are either hacks or have to reimplement lots of things that they shouldn’t have, and the right thing to do is to go down one step in the stack and use HarfBuzz directly. This is also a good opportunity to get rid of our multiplicity of font backends, so expect some HarfBuzz love in WebKitGTK+ in the coming months.

Improved HTML5 media support

The final assault on the Flash empire is about to start, and we want to be ready. We already have support for it, but the WebKitGTK+ team (with a new Igalian, Philippe), is already busy fixing all the bugs and implementing all the missing features.

turbocharged libsoup

A lot is on the pipeline for the tasty library. As I mentioned in previous entries, during the 2.27 development cycle Dan realized some of the things we were trying to bolt on on the library would be much easier if some of its internals were revamped, so he put in motion a bold plan to address this. With that in place, a couple of our biggest regressions (HTTP cache and Content-Encoding support) should be easier to kill.

The bugs! The regressions!

Yes, yes, that too! Be sure to report all of them.

Say you are debugging some feature in your program that is enabled with some command line paramater (”random” example: the –private option in Epiphany for private profiles). One way of passing this to gdb is the –args flag, but another one is to pass them to run/r in the prompt, like:

(gdb) r –private

You do your stuff, and then you decide you need to see what happens without the option. One “obvious” way to do it would be to write, after the previous line:

(gdb) r

Right? Wrong. From the GDB manual:

run with no arguments uses the same arguments used by the previous run, or those set by the set args command.

So you’d be basically running your program with –private again. The right way to do it, as the manual says, is to reset the arguments with ’set args’.

I wonder how many silly things I have done through the years without noticing because I didn’t know this.

To begin with, one of the most visible things that were done in this release is the resurrection of the AdBlock extension, which was the last lonely point to address in our TODO list for 2.28:

Also in 2.27.92, we added support to import all your passwords from the old gecko profile. This requires an optional compile-time dependency with NSS, but I encourage all distributions to enable it to avoid a pretty serious data loss scenario. Together with the cookie import (which landed a long time ago) this should safely bring all your data to the new WebKit world, but I encourage everyone to test this as much as possible before release, since losing data is one the worst kind of bugs there can be.

Another little thing that landed a while ago is a small epiphany extension called ‘Soup Fly’. With it you can see the status of the SoupSession Epiphany is using, with all the messages in it and their state:

It’s already pretty useful to figure out some things (like, “does libsoup think it has loaded all resources in this page?” or “is this resource not loading because the server is not answering or because libsoup hasn’t requested it?”), but we have plans to improve it more in the future, extending its introspection superpowers. (Note to GNOME artists: an icon with a cute fly would be awesome for this! nudge nudge, wink wink).

Speaking of libsoup: one of the things that I think have worked out better in this whole story is the relationship between WebKitGTK+ and libsoup. Since we dropped the CURL HTTP backend and went libsoup-only, things have improved a lot, and very fast: missing features landed, like SoupCookieJar, SoupContentSniffer or SoupProxyResolverGNOME (and others in the backburner for 2.30, like SoupCache, content encoding support and the “big IO rewrite“), a lot of bugs were fixed and in general our networking code improved by leaps and bounds. Most of the credit goes to the libsoup maintainer, Dan Winship, so buy him a truckload of his favorite beverage the next time you see him around. And of course, all this benefits everyone else in the platform using libsoup, which makes it even better; more succintly:

Another area that saw a lot of improvements was accessibility. With the help of great minds like Joanmarie Diggs each release saw a constant stream of improvements, which hopefully moved our a11y status from “OMGWTF” to simply “hum…”. Our tracker bug for this topic is this, and this is an area I’ll definitely visit again during the 2.30 cycle, since one of my goals in life is to be able to fix bugs faster than Joanmarie is able to open them. Yeah, I know, impossible.

One interesting thing (interesting in the Chinese sense, that is) about working with WebKitGTK+ is that it has so damn big in some senses that you keep hitting obscure corner cases in several tools. Not so long ago, for example, make dist stopped working completely for me, spouting some nonsense about an argument exceeding some maximum length limit. After some investigation and the help of the autotools folks it turned out that between our non-recursive setup and our file count we had hit a limit in GNU make itself. Or that other time when I wasted a couple of days chasing phantom crashes in WebKitGTK+, only to find out it was a bug in GNU ld to begin with. This was already fixed in CVS HEAD though, so that was doubly frustrating.

In short, 2.27.92 is out, we have fixed many dozens of bugs since I last blogged, and the browser is definitely getting there step by step. Go and test it, and reports all those pesky bugs in our tracker. In my next post I’ll talk a bit about our plans for 2.30, which include buzzwords like “GNOME Shell”, “HarfBuzz”, “DOM bindings” and “have you fixed all those regressions yet?”.

One thing I’ll try to do before I leave is to spend some time with the WebKit guys and try to get some serious hacking going (in my case, I’ll try to finally kill my a11y nemesis bug, which shall remain linkless), so if you want to join us or want to ask anything about WebKit just grab me and ask if you see me.

This is old news by now, but some of you might not know that the ECMA committe responsible for JavaScript decided last year to pretty much do a full reset and try to move forward step by step instead of doing everything and the kitchen sink in one go; that is, instead of the ES4 revolution we would have the ES3.1 spring cleanup. Well, 9 months later and, ironies of life, the next standard will be called ES5 instead of ES3.1 (although it’s still an incremental improvement), and the final draft is already available (PDF).

So, what’s in it? These google slides do a pretty good job at introducing the changes, but I’ll try to do a warp-speed summary here:

• A new ’strict mode’ to ease robust and defensive programming. You can look up the details in the slides, but a single feature would have been worth it for me back in my litl days: failed assignments throw an exception in strict mode.
• Function.prototype.bind to fix one of the first WTF moments one has when learning JavaScript: closures do not capture ‘this’.
• Higher order array methods: map, every, some, filter, reduce… all are there.
• Built-in JSON implementation.
• getter/setter properties, plus syntax for fine grained control of properties access.

From my limited experience with JavaScript I think this fixes some obvious issues in the language, while others are in the backburner for future revisions (lexical scope, const, destructuring assignment, …), so I’d say things are looking pretty good.

Of course, the bigger issue is: should we require the JavaScript in GNOME to follow ECMA standards (ES3 now, ES5 and following in the future) in order to be able to use any compliant implementation, or should module owners be allowed to use vendor-specific extensions if they think it’s in their benefit to do so? I guess that’s up for debate, but it seems to me that we live in too interesting times to paint ourselves in a corner with a given implementation at this point.

• gtk-doc support was integrated into the build system. There’s still a few rough edges, but hopefully it won’t be too long now before the full API documentation is available at, say, library.gnome.org.
• l10n support. All text in warnings, dialogs and GObject properties is marked for translation using gettext, and everybody is welcome to contribute new translations!
• A full-fledged printing API using GTK+’s GtkPrintOperation.
• Spellchecking support through Enchant.
• Error reporting. A new signal, WebKitWebView::load-error will be emitted when there’s an error during the page load. You can do nothing, and a default error page will be shown, or handle the signal yourself and show some customized error UI.
• Caret browsing mode has been added. It still has some bugs and missing features (notably, interaction with forms is kind of shaky), but I think it’s quite on par with the support in Gecko at this point and not bad for the first stepping stone.
• After the a11y hackfest and the great help from Willie and Joanmarie, a lot of improvements to the ATK support have landed. There’s a lot to cover here, but same as with caret mode we’ll keep improving with each release.
• And as usual, lots of small bugfixes all over the place.

That’s quite a lot of stuff don’t you think? I think we are making great progress, with contributions from the whole team, so let’s keep rocking!

The big visible things on this release are preliminary support for the HTML5 media tags (it works, I saw the Transformers trailer with it!), and a new signal, WebKitWebView::new-window-policy-decision-requested, which gives us the means to properly handle, at last, links with target=_blank (already available in Epiphany trunk). As usual there’s a bunch of bugfixes and other improvements, the complete NEWS file is:

================
WebKitGTK+ 1.1.4
================

What’s new in WebKitGTK+ 1.1.4?

- WebKitWebView gained uri and title properties, deprecating the
usage of the title-changed signal.
- Basic functionality for HTML5 media tags has been achieved; there
are many unimplented methods, and rough edges still, though.
- Font rendering received quite some love, with layouting, and
memory handling fixes, and at least one less crash.
- A new signal, new-window-policy-decision-requested, has been added
to WebKitWebView, that makes it possible for the application to
correctly decide what to do when new windows are requested.
- A bug that made tooltips for consecutive links not update their
location was fixed.
- Several improvements were made to the HTTP backend, including
making it more robust when talking to servers which send bad
Content-Type headers.
- WebKitWebView now uses the GtkBinding system to handle key events,
which means that the user is now able to customize the keys used
for various operations, and that many subtle bugs have been fixed.