Who knew we still had low-hanging fruits?

Earlier this month I had the pleasure of attending the Web Engines Hackfest, hosted by Igalia at their offices in A Coruña, and also sponsored by my employer, Collabora, Google and Mozilla. It has grown a lot and we had many new people this year.

Fun fact: I am one of the 3 or 4 people who have attended all of the editions of the hackfest since its inception in 2009, when it was called WebKitGTK+ hackfest \o/

20171002_204405

It was a great get together where I met many friends and made some new ones. Had plenty of discussions, mainly with Antonio Gomes and Google’s Robert Kroeger, about the way forward for Chromium on Wayland.

We had the opportunity of explaining how we at Collabora cooperated with igalians to implemented and optimise a Wayland nested compositor for WebKit2 to share buffers between processes in an efficient way even on broken drivers. Most of the discussions and some of the work that led to this was done in previous hackfests, by the way!

20171002_193518

The idea seems to have been mostly welcomed, the only concern being that Wayland’s interfaces would need to be tested for security (fuzzed). So we may end up going that same route with Chromium for allowing process separation between the UI and GPU (being renamed Viz, currently) processes.

On another note, and going back to the title of the post, at Collabora we have recently adopted Mattermost to replace our internal IRC server. Many Collaborans have decided to use Mattermost through an Epiphany Web Application or through a simple Python application that just shows a GTK+ window wrapping a WebKitGTK+ WebView.

20171002_101952

Some people noticed that when the connection was lost Mattermost would take a very long time to notice and reconnect – its web sockets were taking a long, long time to timeout, according to our colleague Andrew Shadura.

I did some quick searching on the codebase and noticed WebCore has a NetworkStateNotifier interface that it uses to get notified when connection changes. That was not implemented for WebKitGTK+, so it was likely what caused stuff to linger when a connection hiccup happened. Given we have GNetworkMonitor, implementation of the missing interfaces required only 3 lines of actual code (plus the necessary boilerplate)!

screenshot-from-2017-10-16-11-13-39

I was surprised to still find such as low hanging fruit in WebKitGTK+, so I decided to look for more. Turns out WebCore also has a notifier for low power situations, which was implemented only by the iOS port, and causes the engine to throttle some timers and avoid some expensive checks it would do in normal situations. This required a few more lines to implement using upower-glib, but not that many either!

That was the fun I had during the hackfest in terms of coding. Mostly I had fun just lurking in break out sessions discussing the past, present and future of tech such as WebRTC, Servo, Rust, WebKit, Chromium, WebVR, and more. I also beat a few challengers in Street Fighter 2, as usual.

I’d like to say thanks to Collabora, Igalia, Google, and Mozilla for sponsoring and attending the hackfest. Thanks to Igalia for hosting and to Collabora for sponsoring my attendance along with two other Collaborans. It was a great hackfest and I’m looking forward to the next one! See you in 2018 =)

Firefox 3.5 lançado!

O Firefox 3.5 foi lançado, e essa é uma boa notícia. Significa que os navegadores livres e/ou que respeitam padrões abertos continuam deixando comendo poeira os navegadores legados com o Internet Explorer (especialmente o 6, que ninguém merece, né?).

Entre outras coisas, o Firefox 3.5 tem performance de javascript muito melhor, parecida com a do Epiphany 2.27.3, e suporta bastante coisa de HTML5, incluindo as tags de audio e vídeo. Muito importante com relação a isso, é que ele suporta por padrão os formatos abertos (assim como a WebKitGTK+, que usa GStreamer, mas o suporte às tags ainda não funciona 100%). Tem algumas páginas muito interessantes para acompanhar a ‘adoção’ da nova release: http://downloadstats.mozilla.com/.

As pessoas devem saber da minha relação de amor é ódio com a Mozilla – mesmo hoje o navegador não se integra bem com meu GNOME, a API de embedding deixa muito a desejar, mas ninguém pode negar que o Firefox foi o que trouxe um clima de abertura para a Web, e exigiu que todos começassem a se preocupar com padrões, desempenho e qualidade. Se você usa um sistema operacional proprietário, largue logo os navegadores proprietários e use uma coisa que presta! =)

My first patch to WebKitGTK+ committed!

Well, not really my first patch. But the first thing I tried to mess with when I first started looking at WebKitGTK+ was the WebKitNetworkRequest object, because I was fancing the idea of writing stuff such as HTTP transactions monitoring, and things like that. So I wrote a big patch which exposed the internal WebCore object (ResourceRequest) fully through our own object. That was back in early 2008. We have come a long way since, and through all these months I got a broader perception of what kind of APIs we need, and how WebCore works. We also decided on going soup-only, which had a huge impact on what the final patch actually looks like.

The patch which finally got committed this week is, how can I put it, VERY different from what I had originally written. You can take a look at the long discussions about it in the bug report I used to track progress. I think I should point out that Marco Barisione and Christian Dywan were crucial in helping me get going with my contribution to WebKit at that time.

What this change gives us is basically the fact that a WebKitNetworkRequest now carries more than just the URI for the request (it actually carries with it a reference to the SoupMessage that will be used later in the request processing, which we are planning to expose in the near future), meaning that when WebKit API gives you a request, and you use it to cause a new load (for, say, opening in a new tab), you still get all the headers that were supposed to go with the request, so you don’t lose things such as, for instance, Referer. So, now, after more than 5 years, the bug that complained that Epiphany did not set Referer (and Galeon before that) for new tabs is finally closed.

By the way, this problem has been fixed for Mozilla’s browser back in 2002, but the embedding API is still buggy up to now. There is still hope, since there’s an attached patch that fixes the issue to be reviewed, and landed. If anyone is reading, it might be a good oportunity to get this fixed in there as well, so that users of applications that use Gecko’s embedding API can also benefit!

Mozilla Corp e suas idéias sem noção…

Há algum tempo atrás a Mozilla Corp decidiu obrigar o Debian a parar de usar as brands Mozilla nos pacotes que distribui. O problema é que o Debian não quis aceitar o acordo de receber uma ‘licença’ especial para usar as marcas com a condição de que devia informar aos usuários que se modificassem o Firefox deveriam trocar o nome. O Debian normalmente não aceita tratamento especial, portanto acabou trocando o nome do Firefox pra Iceweasel.

Agora parece que a Mozilla Corp resolveu atrapalhar ainda mais as distribuições GNU/Linux. Ou elas mostram uma EULA ou tem de mudar o nome. Eu recomendo fortemente à Canonical mudar logo o nome e, como disse alguém, virar as costas pro Firefox. Ou, melhor ainda, trabalhar no Epiphany e no WebKit e esquecer a Mozilla Corp.