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 actually enjoy reddit’s ads!
Keep up the good work!
Actually, that’s totally true. Reddit’s ads are pretty good 🙂
From the NEWS file:
“- Reimplement direct search on the location bar (#583795)”
That’s actually the last thing that still prevented me from using Epiphany 2.27 full time!
Thanks a lot 😀
Ephy with Webkit is even much more awesomer that Ephy<=2.26 already was!
> 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.
Does that mean epiphany will end up being linked to NSS ? Wouldn’t it be better to use command line tools to do the conversion and avoid epiphany depending on NSS altogether ?
It will link with NSS, at least in 2.28, yes.
I went through the ‘let’s just dlopen NSS’ route, but I ended up giving up when I saw the amount of hacks I’d need to do, and how fragile the whole thing would be.
What command line tool would you recommend to do this? Can you guarantee that it will be completely compatible with NSS?
I hear that Google Chrome does not support plugins on Linux. Since that browser is Webkit based I was just wondering if the Webkit version of Epiphany has the same issue?
We have plugin support, although Java does not work. But Flash does.
xan, NSS does provide command line utilities to handle its databases, that I think most distros ship nowadays. I think what you need is certutil and possibly modutil. On Debian, they are both in the libnss3-tools package, though they strongly lack documentation.
Another option would be to have your conversion be done by an external program that would be linked against NSS. That way, even if the epiphany packages would depend on NSS (which they would anyways, if you use the NSS tools), epiphany itself wouldn’t have a runtime dependency on it. Only the conversion tool.
xan: IIRC, java uses some xpcom stuff, right ?
Looking forward to stable Webkit Epiphany, and really glad that you’re making the transition. Thanks for keeping us posted! And nice lolcat pic. ^.^
glandium: yeah, doing the tool myself was one thing that I considered, and it certainly is better than linking the ephy process with NSS. I might do it for 2.28.1 🙂 I’ll check the stuff you mention too anyway, see if there’s something I can use.
About Java using XPCOM, might be, but I think it must also use the new plugin APIs, since the java plugin works in other ports. I think it not working in WebKitGTK+ is just a deficiency in our implementation.
Here’s what I would like to see.
An Epiphany Instance would be cool.
Not like raw WebKit GTK, but a Epiphany rendering which is connected to the keyring and custom settings.
So one could easily build prism-like single apps, which wouldn’t need to keep their own keys and cookies around 🙂
This could also lead to a chromium like “instances” features, so that one page/plugin doesn’t crash the whole browser.
Is this planned for 3.0?
“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”
I guess WebKitGTK+ is hiding the unnecessary library symbols i.e .the reason wasn’t too many exported symbols?
Great work dude!
I am very excited about this, because not having the AdBlock extension was one of the things that prevented me to use Epiphany-WebKit in a daily basis. Also, the SoupSession thing look very itneresting also for web developers. Great work, mate!
Hey,
I’m already using epiphany-webkit and it really is getting ready to rock.
One thing I still really miss is the ability to scroll with middle mouse like I could though an extension in epiphany-gecko. Point is, that I use a tablet pc and I really like to hold down the button on the pen and scroll by moving the pen up and down. This works okay in epiphany-gecko, but really really great in evince, maybe it would be possible to get it the same way in epiphany-webkit?
Hey,
I’m already using epiphany-webkit and it really is getting ready to rock.
One thing I still really miss is the ability to scroll with middle mouse like I could though an extension in epiphany-gecko. Point is, that I use a tablet pc and I really like to hold down the button on the pen and scroll by moving the pen up and down. This works okay in epiphany-gecko, but really really great in evince, maybe it would be possible to get it the same way in epiphany-webkit?
Cheers,
Mike
@eero: we are using -fvisibility-hidden, so I think we are doing OK in that regard.
@Mike: doing something Chrome-like is an interesting idea and definitely in our possible plans, but it won’t happen for 2.30 🙂
@Michael: I believe that extension already is working in ephy/webkit, although in a very rough form. I guess we can try to check evince to see what it does there, but please open a bug about it so that we don’t forget.
Pingback: GNOME Commit-Digest » Blog Archive » Issue 49
How do you get adblock working on 2.27.x? In general how do you gain access to epiphany-webkit extensions?
Xan, flash ads are not block by the adblocking, while on midori (0.2.0) it all gets blocked without a problem. I am using epiphany 2.28.1.