Together we can rule the Galaxy – Epiphany 2.28 and WebKitGTK+ 1.1.15.x

made-to-share-274x140

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.

Posted in General | 14 Comments

A GDB public service announcement

Possibly I’m about to make a fool of myself saying this, but since I wasted some time a few days ago I might help someone doing it.

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.

Posted in General | 5 Comments

WebKitGTK+ 1.1.14 new features

Gustavo has written a nice sumary of all the new APIs in 1.1.14 (yes, all that stuff was only for 1.1.14!), so go and check it out if you are interested.

Posted in Blogroll, General, webkit | Comments Off

The show so far

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:

shot1

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:

soupfly

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:

128968842326568397

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

Posted in General, webkit | 21 Comments

I love this plan. I’m excited to be a part of it. Let’s do it!

Hi from GCDS! Now that both my normal talk and my crazy talk are done I guess I can break the radio silence and say what’s going on like everyone else is doing. I spent a couple of crazy days with Fer preparing our GNOME 1,2.3 talk, although to be honest it was great fun to make up all those jokes and find those videos. For those who asked, he’s preparing a technical ‘Making of’ of the talk, so stay tuned. Because of that I missed some talks and parties, but now that that’s over I’ll try to attend to as much stuff as possible! For starters, yesterday’s Igalia Party was great.

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.

Posted in General | 1 Comment

ECMAScript 5

After the discussion on the Seed proposal thread about what flavor of JavaScript should GNOME as a project use, I made a point of figuring out what’s the current status on the ECMAScript standarization saga.

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.

Posted in General | 3 Comments

Two releases for the price of one

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!

Posted in General, webkit | 5 Comments

WebKitGTK+ a11y (virtual) hackfest

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!

Posted in General, webkit | 1 Comment

WebKitGTK+ 1.1.4

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.

Posted in General, webkit | 10 Comments

Good news, everyone

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!):

progress-in-entry1

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

inspector

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 :)

Posted in General, webkit | 16 Comments