Iocane powder

Unless the enemy has studied his Agrippa, which I have

In a few days we’ll release Epiphany 2.29.90, so this is a good time as any to show a few of the new cool things it will bring.

The big one is, without doubt, good enough support for HTML5 video tag for the Youtube HTML5 beta to work. Pretty much all of the credit goes to the dynamic duo of Sebastian Dröge and Philippe Normand, which have been working tirelessly to improve our media support all across the board. As you probably know we use GStreamer for all our media needs, so if you happen to have the right codecs installed stuff will just work out of the box, like it should. Here you can see it in action, playing one scene everybody should know and love:

Another recently fixed bug is support for windowless NPAPI plugins, contributed by Brian Tarricone. For those of you still enslaved to plugins it should fix a few annoyances, not to mention that it allows for the plugin content to be manipulated alongside the rest of the web content, since it’s rendered directly in the browser window.

The world-famous Diego Escalante, who is doing an internship in our company with the mission of fixing as many Epiphany bugs as he possibly can, reimplemented EphyEmbedPersist on top of WebKitDownload , which will have the visible effect of making those mysteriously broken save-related context menu items work again.

On the same “kill all regressions” mood I spent some time implementing acceptance policies for cookies in libsoup and hooking the new APIs here and there. The result? This pesky items in the preferences dialog should do something again:

When I was not doing that or losing my youth in the depths of WebKit chasing some nasty bugs I’ve also been spending some time on the GObject DOM bindings for WebKit. I’m happy to say that a couple of preliminary patches have been already committed, and the first big-step patch of the process is under active review and hopefully will be accepted shortly, so you should begin to get some exciting new APIs to manipulate web content in a not-so-distant release!

There are just a few of the latest things we have been working on. I’ll, as usual, keep you more or less up to date here, but if you want the gory details of the day to day business, or even get your hands dirty on the stuff yourself, don’t hesitate to join our IRC channels (#epiphany on GimpNet and #webkit-gtk on FreeNode) or mailing lists. Happy hacking!

WebKitGTK+ Hackfest – Day G_MAXINT

Haven’t blogged about the hackfest since the day zero (although others have done a great job), but I guess I have a good excuse since we have been working all day every day, no time for blogging!

A lot of progress was made in many areas, but I can try to give a brief summary:

• Gustavo and myself focused on fixing the form password saving regression during the first days. We wrote the basic code to hook into the webviews using JSC, store the auth data in the keyring, and refactored the Epiphany codebase a bit to be able to show infobars with the available options when submitting a form, like most browsers do. I know this was one of the most painful shortcomings of the browser for a lot of people, so I’m happy to put it behind us.
• Dan, Benjamin and others spent a lot of time hacking on libsoup. The Content-Encoding support landed in both 2.28.2 and master, which should make us render correctly some pages instead of showing gzip compressed garbage. Other things of interest were the GIO Socket support, a requisite for better SSL support (including certificate management) and the so-called URI Loader, which was redesigned and advanced enough for Dan to be able to write basic about: support for Epiphany/WebKit and that is a blocker feature for mail clients that need to support CID URIs (like Modest or Evolution).
• I spent some time finishing my refactoring of the work previously done in the DOM bindings bug. We are not there yet, but I have a quite smaller patch with a reduced scope (supporting a subset of the Node API) which already works and that I’ll try to upload when I’m back in Finland and that should be easier for the reviewers to accept as a first step.
• We enabled the page cache support in WebKitGTK+, which uncovered a series of interesting issues that we spent some time fixing up. On top of that Álex also landed the first step of better cache management APIs, a widely requested feature. Both will be important in providing faster and more responsive web content for our users.
• Oh my God, have to catch a train to Vigo soon and this list is endless!
• Evan and Behdad teamed up to work on a Harfbuzz font backend for WebKit. They were able to make it show some fancy text by the last day, and the current plan is to land this at some point in the first half of the next year, with WebKitGTK+ and Chromium/Linux sharing most of the implementation.
• Cody worked on using the new offscreen rendering support in GTK+ for our theming code. He made great progress, identifying some new features we need on GTK+, and hacking up a GtkOffscreenContainer that might end up going into GTK+ upstream and that was enough to make his proof of concept implementation actually show properly themed widgets in a page.
• Philippe kept rocking on the media side of things, as usual. He finished the HTML5 media control patch which Zan started, and made other nice fixes to our increasingly awesome media support.
• Martin Robinson worked on various cool things when he managed to find some free time in between his eternal quest to find his missing luggage (which AFAIK he only managed to get back on his way back to Barcelona!), including transparency support for WebViews and his improved DnD code.
• What else! We worked on accessibility bugs and random epiphany issues (custom User Agent support by Vincent Untz, send the proper Accept-Language HTTP headers on requests by Mario, respecting web context menus including a way to override them to show the epiphany menu…), making our regression list shorter and shorter, and other invisible but important things like making our binaries both smaller and faster to build.
• We reached some important conclusions on the gaming side of things, like Smash Brothers for the Wii being an insane game, proving that my Ryu totally owns Gustavo’s Ken or finding out about Benjamin’s past life as a Starcraft quasi-progamer. Speaking of games, don’t forget to enter the Konami Code in Epiphany 2.30 .

I’m probably forgetting things, but that’s about it. I think we all had a great time, great progress was made, and I want to thank Igalia, Collabora and the Foundation for their sponsoring and support for the event. Let’s do it again next year!

WebKitGTK+ Hackfest – Day Zero

Arrived yesterday night to Coruña for the WebKitGTK+ hackfest, a couple of hours before Gustavo did. Today he and I kicked off the day zero of the hackfest, before everybody arrives starting tomorrow.

We spent the whole day hacking on form login/password saving, and despite some issues with GNOME keyring being unhappy and dying on us, I can say we made good progress for one day of work:

This is epiphany/webkit master auto-filling my twitter.com login/password after launch, which as some people know is one of our last nasty regressions. There’s still a few things to do, but I’m confident about landing this before we leave Spain. Also, for those of you not following our development closely, the screenshot also shows the twitter favicon, since Gustavo recently fixed our favicon support in master.

Later today, Álex and Philippe joined us. Álex continued working in a tough accessibility bug in WebKitGTK+ he’s been fighting with, and Philippe arrived just in time for a nice dinner downtown. Not bad for one day, considering we were even not supposed to be here today!

WebKitGTK+ Hackfest 2009

You might have heard the rumors, and it’s true: we’ll be holding a WebKitGTK+ hackfest right before Christmas, from the 15th to the 21st of December, 2009.

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!

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

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.

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.

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.

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:

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

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.