Spurred by all this I sat down and added DNT support in Epiphany, which thankfully is an extremely simple spec to implement. It’s now in master, so anyone willing to enable just needs to go to the Privacy tab in Preferences and click:

Now the pages that choose to respect this setting (unfortunately not everyone does; by a long shot), should be able to detect your request. We can see that things are working in the donottrack.us page itself.

Note that the page claims our browser does not support the feature, yet it is enabled; this is because DNT being an HTTP header extension the only way for the page to tell you whether your browser supports it in theory is by having a hardcoded list of supported browsers, which does not include Epiphany. Oh well. Either way, enjoy your newly untraceable goodness, which should make its way into the next unstable release.

Some time ago, in another trip, I proposed anyone who might be reading me to meet up and talk about all things GNOME or WebKit. Turns out I met some interesting people that way (hi everyone from Caixa Mágica!), so let’s try again: if you are reading this, are in Tokyo, and would like me to talk to your friends/colleagues/whatever about GNOME or WebKit I’d be happy to do so. We can also improvise a hackfest or anything else we can come up with. In exchange I only ask of you to show me around (always better with a local) and an unwavering commitment to freedom and justice.

Drop me a line at xan AT gnome DOT org, or leave a comment in this space.

New UI

The most obvious change at first glance is the refreshed UI, which was already covered in some detail in this blog post. Thanks to the hard work of the GNOME Design Team, the GNOME platform hackers and the Epiphany team we’ve got ourselves a completely new toolbar layout with elegant widgets (I particularly like the linked-style back/forward buttons), support for the new Shell application menu, the demise of our menubar and the debut of our ‘super-menu’ holding the less frequently used page specific actions. Not only the browser works better than ever, it now looks better than ever too.

New History

We have been talking about rewriting our history backend for many years now; to give just one example, as far back as 2007 we already had a Summer of Code project to try to fix some of its shortcomings, which were many. The old backend served us well for almost a decade, but it was showing its age: a difficult to understand legacy codebase, a bus factor of 1 and poorly scalable architecture that made storing more than a couple of weeks of browsing history a titanic task. Last year a crack team at Igalia was put together to fix this once and for all. Enter the new age:

• Drop our XML based storage in favor of good ol’ SQLite. Many options were considered other than SQLite, and we could yet again change how things are done internally in the short term, but for the first step we decided to settle on a simple, trusted and performing technology.
• Never block the UI. All actual history accesses are done in a special service thread which communicates its results when they are ready to the user interface. This way things will remain responsive and snappy, no matter how complex your queries are or how full to the brim your history is of non-stop reddit browsing.
• Test it! User data is the most important thing the application handles, and losing your browsing history is the modern day lobotomy. Our new backend is thoroughly tested through unit tests, so your data is in good hands with us.

Thanks to the new backend we can now provide infinite history storage and instantaneous non-blocking search both in the URL entry and the history window, both long awaited features. Other than that, for 3.4 we tried to keep the UI as it was: one thing at a time. For 3.6, though, now that the we are beautiful on the inside, expect some surprises in how you interact with your history data.

New WebKit

As with every release, on time, we ship with the all new WebKitGTK+ 1.8. As usual there are way too many thing to list and they deserves their own blog post, but you can look forward to: the debut of the WebKit2 API (still experimental but with some modules already using it, like devhelp), WebGL, Accelerated Compositing, HTML5 History API, support for the last version of WebSockets, WebAudio, a rewritten favicon database class and loads and loads of bugfixes and improvements.

Less is more

A constant thought in my mind as a module maintainer is to focus our efforts in delivering the best experience we can given our available resources. I believe as a project, both GNOME and Epiphany, we are now facing the difficult choices successful software must go through at some point: stop trying to be everything for everybody, decide what you want to do and for whom, and try to do that really well.

Our new ongoing redesign is a great step in that direction, and I’m glad that we are finally focusing on what I think really matters. I believe 3.4 is our best release ever, with both cool new features and fixes for old major deficiencies, and things will only get better from here. And, a favorite pet peeve of mine, we did all that while massively cleaning up our codebase to make it cleaner and more hackable, a task without much glamour but a big payoff. Our last release, ignoring translations, icons and help files, comes with 214 modified files, 14,959 insertions and 24,341 deletions. For those keeping the score at home, that’s almost 10,000 lines less of code to maintain, read, patch and load!

Thanks!

Thanks to all the GNOME contributors that made possible this release, but a special thanks must go to Igalia for its continued support for Epiphany. We are not only the best WebKit consultancy around, but we are also putting our money where our mouth is by supporting web technologies in GNOME through its browser and beyond.

Work on 3.6 is already underway, so expect a lot more from your favorite webkittens 6 months from now. Until then, you can follow us on IRC, our mailing list, identi.ca, twitter, facebook or our new project page (wow!). Happy hacking!

There’s a lot of new stuff here, so let’s go step by step.

Application menu

The application menu, accessible from its usual location in the Shell, holds actions that affect the entire application as opposed to the currently focused window or tab. You’ll need a fairly recent version of the Shell and gnome-settings-daemon (3.3.4 of both should do, when they are out) to get it working, otherwise the browser will fallback to a lonely “Application” entry in a now deserted menubar.

Also, notice that we now brand ourselves as “Web” in all user visible strings.

New toolbar

The bulk of the changes are here. As you can see the Back and Forward buttons have been visually merged, a fate shared by the location entry and the reload/stop button. The entire menubar is gone, being replaced by a “super menu” triggered by the funny looking button with a gear (more on this later). Everything else that used to be in the default toolbar layout is now gone, as is the ability to edit its contents, making the concept of a default layout more dramatic. Finally, we use a new style for the toolbar, making it seamlessly merge with the window decoration. We think it looks great!

Super menu

In the quest to save as much vertical space as possible in the default layout we have moved all the remaining actions of our menubar into a side “super menu”. Here will live actions related to the current page, although for the moment we have some visitors there en route to their new destination (like the Bookmarks menu, which will live in the new Overview).

The devil is in the details

A lot of other small tweaks and cleanups have happened, too many to mention. From a renewed floating statusbar (now shared with Nautilus), to spacing tweaks, to more thorough use of symbolic icons throughout the UI. Special thanks go to the Design Team, it’s a pleasure to work with them in both the small details and in the big picture re-designs.

Also, one benefit of having a renewed design focus is that it allows you to do this:

135 files changed, 14988 insertions(+), 26958 deletions(-)

Around 12,000 lines of code have been deleted since 3.3.2; the biggest chunk comes from the demise of EphyToolbarEditor and friends, but in other places we have just managed to do the same, or more, with less. This means more energy devoted to make Epiphany really good at what it should be doing, which is what every core GNOME application should aspire to do.

More to come

This is only the beginning, not the end. The Epiphany team will now continue full steam ahead to implement the new Overview, merge the new SQLite history backend, port our extension system to libpeas and many other exciting features, maybe including some surprise gift in the Web Application camp. Stay tuned to this space and, as usual, happy hacking!

Epiphany 3.0

Yes, the Bluetooth/Network icons are all wrong. Sorry Jon.

It’s always hard to summarize months or development in a few lines, but one can always try:

• Epiphany 3.0 uses the (soon to be released) WebKitGTK+ 1.4.0. I’ll write a blog post focusing on WebKit when 1.4.0 is out of the door, but some of the highligts of the release would be: GObject DOM bindings, already used by Epiphany and other GNOME apps. HTTP cache implementation, moved into libsoup later in the cycle. GTK+ 3.x support, which we laboriously kept going through all the development cycle. New APIs for plugin management, icon database and frame flattening, among others. HTML5 media support for fullscreen mode, volume management, cookies and Referer. A ton of bugfixes all across the board, from DnD, a11y, networking, and graphics performance to leak fixes, clipboard handling, history, theming and forms. WebKit 1.4.0 just works a lot better, and you’ll notice the minute you start using Epiphany 3.0.
• UI refinements all over the place: we use a GtkInfobar to inform of session restoration, a Chrome-like floating statusbar (implemented with GeditOverlay) instead of the pixel-eating traditional GtkStatusbar, we let the old, big and hardcoded EphySpinner go, new and nicer custom error pages, …
• The download UI was completely rewritten to fit better in the Shell. No more status icons and floating windows, we now show ongoing download information in a unobtrusive bottom bar.
• We took the GSettings migration as an opportunity to improve a bit our settings. In particular I think we have made the font defaults saner for the modern world, and hopefully people will be happier with how their pages look.

There’s still some small details that we want to improve for 3.0, so stay tuned for 3.0.1 (and more!) soon.

Epiphany 3.2

But we are not resting on our laurels! We are already busy planning and working on the features you’ll see in GNOME 3.2, 6 months from now:

• One of the main themes of the release will be further integration of the browser with the new GNOME UI and design. We are still in the brainstorming phase, but some of the front runners are replacing our menubar with the Shell’s global app menu (more space for your web content!) or integrating our tab/window management into the Shell user experience.
• A desktop that does not consider the Web a first class citizen in 2011 is not a modern desktop. For 3.2 we are going to bring your favorite web applications into the spotlight: hi-res launchers with custom .desktop files, separate epiphany instance per application, minimal chrome-less UI, and much more. Also, we have proposed this as one of the GSoC ideas for GNOME in 2011.
• We are also resurrecting the old idea of killing EphyNode and moving our bookmarks and history storage to something like sqlite, which should give us a much more faster and responsive experience. Martin and I are committed to get this working before I leave the Bay Area in May, so if by that date you see me around and this is not in master or in a git branch you can punch me in the face. Really.

One more thing

A year ago, almost to the day, the WebKit2 initiative was announced. As the project page says,WebKit2 aims to bring the split process model popularized by Google Chrome into the WebKit framework in a way that will allow all ports to benefit from the increased responsiveness, security and stability. At Igalia we have always been interested in bringing this new technology to our GTK+ port, and only a few days ago the last batch of patches in a long series finally landed upstream, allowing everyone to build the GTK+ version of WebKit2 directly from SVN trunk (you can read more details in Alex’s blog post!). We believe a split process model has quickly become a must-have for modern browsers, so we want to announce our commitment to port Epiphany to WebKit2 as soon as it is ready, and make this the default and only configuration available, as in Chrome. We are aiming to have an early alpha to show at GUADEC this year, and we’ll try to deliver a production ready version as early as GNOME 3.4, in 2012. We hope you’ll all be as excited as we are about this new stage in the history of the GNOME browser!

Until next time, happy hacking from your favorite band of gnome web hackers.

If this sounds like something you’d like to do drop me a line to any of my multiple mail addresses (I’m sure you’ll manage to find at least one of them) with any background information that you consider relevant.

PS: We are extremely flexible in both location (ask me about my last 9 months travelling around the world) and how you distribute your working hours, so we should be able to accommodate pretty much anyone that is both human and living on planet Earth.

Others have already blogged about the event (Mario, Gustavo, Alex, Diego in multiple occasions … eh…) in some detail, so I’ll just try to give some extra information about some of the things that I did.

JIT + Oprofile

One of the few negative side effects of the not-so-recently acquired JIT superpowers of JavaScriptCore is that JIT-generated code does not play very well with the tools we use everyday to debug and improve our code: gdb will have no idea of the name of the chunks of generated code it passes through (since they have none), and will print something unhelpful like “#9 ??”, profile tools like oprofile and sysprof will have exactly the same problem, so you’ll be unable to know which, if any, of the generated code is the culprit of excessive CPU usage, valgrind does not expect executable code to modify itself at runtime, and will freak out and crash unless instructed to not do so, etc. Fortunately some of these problems have solutions, so I spent the beginning of the hackfest reworking (to please the Reviewer gods) a beautiful patch started some time ago by Holger Freyther and the wizards of the University of Szeged to instruct oprofile about our JIT maneuvers. With this in place the tools is able to know the context of the JIT memory chunks it goes through, and is able to go from some useless complains about anonymous memory ranges to printing something like:

141       0.1910  8581.jo   <jit-func>:fannkuch[tests/sunspider-0.9/access-fannkuch.js:5-62]

Nice!

about:plugins

Another topic where I spent a few days is the long struggle to resurrect “about:plugins” in Epiphany. While Dan was busy kicking libsoup into shape so that we can implement about: URLs in a non-terrible way, I worked on adding the APIs in WebKitGTK+ that the browser will eventually use to fetch the plugin data. A couple of patches (here and here) have already landed, and we can now query WebKit for all the plugins it has loaded in the session, ask information about them, and even disable and enable them at runtime. Because seeing is believing you can see a hacky implementation of the about page that I have implemented locally:

Rest assured, this will look nicer (and will have more data and features) when it finally lands upstream!

Tradition

It was of course great to see everyone again, both colleagues from Igalia and all the other hackers, and I hope we’ll be able to repeat the event again next year. If we manage to do it a third time this would pretty much become an ancient tradition of the GNOME community as far as these things go. Thanks to all the contributors and sponsors (Igalia, Collabora and the GNOME foundation) and until next time.

It has come to my attention that the GNOME Foundation is interested in my DEFCON app in order to better enforce the new Speaker Guidelines in current and future GUADECs. I’m happy to announce that the app is in fact for sale, so just contact xlopez at igalia.com for details.

PS: starting price is 500 EUR, it includes a tactical nuclear strike to the talk site when DEFCON 1 is hit.

2.30

For 2.30 we focused on fixing all the regressions introduced by the switch to WebKit in 2.28. Overall we did a pretty good job, and there’s only a few things missing to reach the no-regressions goal. Here’s everything that used to work in 2.26, didn’t work in 2.28 and that we fixed for 2.30: middle-click to open clipboard contents, bring back our old context menus, up arrow functionality, do a web search with the URL entry contents on Ctrl+Enter too, EphyEmbedSingle::handle-content signal for external download managers, favicon support, send HTTP ‘Accept-Language’ headers with the user language preferences, custom User-Agent support, javascript: and mailto: URI support, close and movement DOM methods for window, shift+click in text areas, and, yes, form authentication auto-completion.

Wew.

OK, so that’s a lot of stuff, but we were not happy with only bringing back old functionality, we also made some improvement here and there:

GNOME Keyring storage for form auths + Infobar goodness:

In 2.30 not only all your form authentication data is stored in the keyring, but we walked the extra mile to migrate the data in the gecko profile to the new format (not a particularly funny thing to do) and we now show a shiny infobar each time you are about to submit never-seen-before data:

Page cache

After much painful debugging we managed to make the Page Cache support in WebKitGTK+ stable enough for widespread usage. These means that when a page passes some preconditions its whole in-memory representation will be saved for some time, making going back to it with the Back/Forward button blindingly fast. Fast is Good.

Favicons in the Tab Menu:

Back in 2007 I opened a bug suggesting to put favicons next to the page titles in our Tabs menu, arguing that this would make it much much easier to identify a certain page when you have lots of tabs opened; having said that, I promised to attach a patch with the fix “soonish”.

3 years and one week later Olivier Tilloy probably got fed up of waiting and decided to just send a patch himself, making our lives (well, at least mine) much better:

Hey, can you see the bug in that screenshot? An opportunity to contribute!

Disable all plugins at runtime:

Back in the day all you could do in Epiphany was to disable the Java plugin, which nowadays is, to say the least, a feature of questionable usefulness. What we all want to do, surely, is to disable Flash unless we actually need to use it, right? Actually, make it all plugins in general, just in case:

Now

And what about the next release? We haven’t stopped working. In fact at Igalia we are increasing our commitment with the platform, and we are growing the team: Alejandro García is working on rendering performance and in reminding everyone how many years it takes to get anything done in software, always; Sergio Villar is working on libsoup, aiming to finish the disk-cache for 3.0; Mario Sánchez is focused on our accessibility support, fixing bugs left and right (with the help of two of our interns, Diego Escalante and José Millán); Philippe keeps rocking on the media front, and our most recent hiring, Martin Robinson is rewriting and improving our DnD support so fast that it’s hard to keep track of it! Oh, and yeah, myself I’m still working on the GObject DOM bindings, a new post about all the new features I’ve added these past weeks is way overdue.

And what about Epiphany? For the next release (due on Wednesday) you can expect a bunch of bugfixes and some UI improvements. One that I’m enjoying a lot is something I implemented last week; I finally got rid of our statusbar for good, and now by default we’ll show contextual messages in a Chrome-like embedded statusbar (which we already had, but that I have reimplemented and made visible by default):

More vertical space for web content, less code!

My goodness was that cheese good

After finishing some loose ends in a remarkable place I found in Bairro Alto the GObject DOM bindings are in good enough shape to start doing some damage in this world (queue video that probably won’t appear in Planet GNOME, click into my blog to see it):

What you just (hopefully) saw is a GTK+ button that, when clicked, gets all the links from its cousin WebKitWebView and makes them do a small bounce, all with the DOM APIs you know and hate^Wlove exported through GObject.

For instance, to get all links simply call webkit_dom_document_get_links on the WebKitDOMDocument associated with the WebView, which will return a WebKitDOMHTMLCollection. Now we just iterate through the elements, get the WebKitDOMCSSStyleDeclaration associated to each one, and set the CSS properties we want on each one. Simple as that! No “evaluate this string as JavaScript”, and no using the JavaScript bindings through JavaScriptCore. In fact, since we are generating our own bindings instead of using the JavaScript ones, we can get the proper semantics for GObject toolkits instead of having to live with the decisions other people made for other languages and contexts. You can see the code snippet here; I use a two-step animation instead of using the full-blown css transitions because of a small technical issue that I didn’t want to fix before pushing this post, but of course we should be doing it right in the future. In fact, we should create proper APIs for CSS animations in general, not too different from what you have in, say, Clutter.

Most of the code for this is already in Webkit trunk, and now that the initial phase of the work is done I keep improving the code incrementally and pushing the patches to bugzilla, where my compadre Gustavo promptly reviews them. Now if you’ll excuse me I’ll go to expose all events as glib signals on the DOM objects, watch this space (or the upstream bug) for more updates. Happy hacking!