Iocane powder

Yesterday we released WebKitGTK+ 1.1.14, Epiphany 2.27.92 and Epiphany-Extensions 2.27.92. I haven’t blogged about releases in a while (sorry!), and as the good people at Ars Technica mention development is moving at a “swift rate” (btw Ryan, you can remove the ugly hack to get the contents of the page from your app and use the new and shiny WebKitDataSource APIs) , so there’s a lot of ground to cover. I won’t go through all the APIs and fixes we have done in the last months though, you can always check the NEWS file for a brief summary, or check our documentation page to see what new APIs landed on each release.

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?”.

I didn’t blog about the 1.1.5 release (although Gustavo did, much better than I do as usual), so now that 1.1.6 is out I’ll make a 2×1 post with the highlights.

• 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!

Interested in WebKitGTK+, a11y or both? This Thursday (April 9th 2009), from 14:00 UTC onwards, we’ll hold a virtual a11y hackfest on #webkit-gtk at irc.freenode.net. Willie Walker from Sun will join us, and we’ll try to move forward and set up a plan to fix this last blocker in the WebKitGTK+ integration into GNOME saga. See you there!

So, another two weeks, another release. I suppose nobody would have noticed, but we are releasing on Mondays instead of Sundays because we figured it was better to have reviewers around for the inevitable last minute commits. This time we helped Darin to fix a nasty regression on IRC which would have been a shame to ship with, so yeah, it happened again.

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.

Update: in good old brown paper-bag bug tradition we messed up the soversion calculation in 1.1.2, so please use the new and improved 1.1.3. Sorry for the trouble 🙂

—

As promised, just before GNOME 2.26, two new releases.

First, WebKitGTK+ 1.1.2, now from our brand new website (created by Christian Dywan, kindly hosted by Igalia). It brings two weeks of  improvements, this is the NEWS file:

– Added support for downloads: a new signal, ‘download-requested’,
will be emitted by WebKit when a download is requested. On top of
that, the download process has been encapsulated in a new object,
WebKitDownload, which allows the user to control it or to start
new downloads from the client side.
– Added webkit_web_view_get_encoding to get the automatic encoding
of the current page.
– Added GObject properties for ‘encoding’ and ‘custom-encoding’.
– Added ‘javascript-profiling-enabled’ property to the WebInspector,
which allows to enable and disable the profiling functionality.
– Added API to create and add history items to WebKit’s history.
– Improved debugging support with WEBKIT_DEBUG environment
variable. Most of the settings will only give useful output for
debug builds, but WEBKIT_DEBUG=Network will log all HTTP traffic
form libsoup to console. See WebCore/platform/gtk/LoggingGtk.cpp
for all the options available.
– Lots of bugfixes.

Get it in our download page!

One last thing about WebKitGTK+: we plan to release one *unstable* 1.1.x version every two weeks until GNOME 2.28, where we’ll release a new stable 1.2.0 version (basically, we follow GNOME/Kernel versioning system). As in GTK+, the stability of newly introduced API during the development cycle is not guaranteed; we won’t break it willy-nilly, but we’ll do it if we feel we have to in order to get the best possible API.

Second, the first Epiphany release of the WebKit era: Epiphany 2.27.0. This is the first unstable release of the 2.27.x cycle, and the goal is to get as many people as possible testing it to have a solid 2.28.

What’s in it?

We have some new pretty eye candy, like the new progress-in-entry (thanks to the GTK+ guys for the functionality and to Benjamin Berg for the emergency theming fix!):

We suppor the WebKit WebInspector, with similar functionality to the Firefox Firebug extension:

We are also fixing “historical” bugs, like an option to force all windows to be opened in a tab (gconf key /apps/epiphany/general/open_new_windows_in_tab), or storing all auth data in gnome-keyring (already working for HTTP auth if you pass –enable-gnomekeyring to WebKitGTK+, storing auth data from forms is still missing).

We have done a lot since those early snapshots that were shipped with 2.22.x and 2.24.x (until we removed them because people thought that was the state-of-the-art webkit backend, which has always been in trunk and has never been released until now), and the browser is well into ‘dogfoodable’ territory, so I encourage everyone interested to give this a try and report all issues.

Thanks to all the contributors to WebKit and all the other modules we use, it’s a pleasure to be one little cog in the machine 🙂