| Subcribe via RSS
This Arstechnica article is quite interesting…
Also, NPAPI support is already in the Gecko web rendering engine.
I’d like to correct a perception here: NPAPI plugins are supported in QtWebKit (current SVN and future releases) and WebKitGtk. In fact, Marc Ordinas i Llopis made it work months ago!
Everybody have heard that WebKit is the new cool kid. Here is one reason: it is rather easy to hack on. My colleague at Collabora, Siraj Razick, mixed up QWebView and QGraphicsItem to allow developers to put the Web inside a QGraphicsScene. As he demonstrates, you can do crazy graphics with that.
From there, I went to look at how we can implement the same behaviour we have in one of the popular mobile browser these days. Here’s the result: stefani.ogg (Stefani is the name of our hacking app).
In this video, you can see that each time I click on a paragraph, its content is zoomed to fill the screen. If you click again, you get back to the full page view. At all time the page is live and active (it isn’t a static image), although that can prove to be an issue (like mistakenly clicking on a link while in full page view).
You can try it if you want, just keep in mind that this is a quick prototype and it doesn’t really support scrolling yet. The code is here: http://git.collabora.co.uk/?p=user/pierlux/stefani.git;a=shortlog;h=refs/heads/pierlux-zoom
Now more details on how this works: on double click, I do a hitTestContent() at that position. With a patch we wrote, you can access the HitTest’s bounding box. That is how I determine on what to zoom. After that, it is simple mathematics, signals and QTimeLines.
Granted this method is rudimentary and does not always gives the best result, it works with patched current available API. A more elegant solution (which we may write in the future), would be to use a DOM API and access the node that was clicked on. From there, you could go up the DOM tree and see if a particular div would be more interesting to zoom on (ie, if a <p> tag is contained in a <div>, zoom on that <div> might also contains the title of the paragraph). But first, we have to write that Qt DOM API :).
Every fix doesn’t call for a blog post, but this one deserves it. It all started when Jonathon Jongsma found a way to make text disappear in QtWebKit on May 27th. So he raised a bug. He and I started working on fixing it. We rapidly found that WebKitGtk was also affected, but it was unreproducible on the Mac port.
We dove into the code: “grep selection”, GraphicsContext::drawText(), Font::drawText()… but nothing was really different (there) in the Qt or Gtk port which could explain why the text wasn’t being redrawn when changing the selection.
That’s when I discovered git bisect. Since we had established that the bug wasn’t there when QtWebKit was snapshot for Qt 4.4.0, I had a good place to start. So after recompiling QtWebKit some 15 times (yes, it took around 3 work days!), it pointed me to this changeset. Lucky for us, it was related to the bug (text rendering).
After some digging into the patch, I contacted the author, Dan Bernstein at Apple, and we looked at it together. In little time, he was able to find how to reproduce it on the Mac too. This was now a WebKit wide bug! Some back traces later and some trials: we came up with this fix. Pretty simple, isn’t it? barely 16 chars. Yet, these 16 chars cost around 1200$* in direct labour time and 3 engineers were involved.
Some will say this could have been prevented with proper tests. It happens that it was a special case on the Mac, but all other ports always went through it. Dan now added a pixel test.
The morals of the story are:
One question lasts: how come it took over a month and a half before someone found it? 
* This number is based on market mean hourly rate since exact rates are unknown
It was really cool to get to San Francisco and finally meet IRL other WebKit devs. Kudos for the event!
I am surprised I didn’t encounter this bug myself since I use a keyboard layout with dead keys (French Canadian): until yesterday, it was possible (but with no good results) to input complex or some case of simple text in a web page with WebKit/Gtk+. For example, if you don’t have a ‘à’ key on your keyboard, you have to use a dead key ‘`’ first, then press ‘a’, well WebKit/Gtk+ would simply flush that ‘`’ you first entered. A 20 line patch completed the work started by Alp Toker and Christian Dywan among others to get Input Method Context supported.
I didn’t know dead keys were processed by the input method. It did require some searches to finally find how this works (I have to say, the GtkIMContext documentation is minimalistic or lacks an overview).
Now, the news is that not only can you enter accentuated characters like ‘à’, but you can now also use the other exotic (to me anyway ) Input Methods and they’ll actually work. With the upcoming fix on Asian fonts, we’re going to have a fully working world class web rendering platform.
Update: There seems to be some quirks left with Japanese for example, but I can’t be blamed, unfortunately I don’t understand it. I couldn’t know it wasn’t completely working.
Sad news for HTML5, while Ogg Vorgis/Theora were not necessary to make HTML5 work, a standard codec is needed to make some part of HTML5 usefull - the part I worked on for WebKit/Gtk+. This point has been repeated over and over: all browsers implemented HTML5 needs to have a common codec.
While there is no default image format in the HTML* spec, we were lucky nobody ever used their patents against JPEG. In fact, it is most probably because of said patents that Apple and Nokia were reluctant to include Vorbis/Theora on their OS or their phones.
Someone has to fix that patent system!
I’ve been working on bringing support for media tags in WebKit/Gtk+ in the past weeks. Based on Antti Koivisto’s work on the general WebKit support for the tags and his QuickTime implementation, I was able to provide the basics for this to work.
Sure there are sharp corners right now, it’s a good start. While I did the backend part, connecting WebKit and GStreamer, Alp Toker did a GStreamer sink for Cairo that completes the work. You can see the screenshot on his blog.
Media tags will enable web developer to integrate video in a page as easily as it is for an image nowadays. You could eventually implement a complete media player within a HTML file. With all the major browsers publicly announcing their progress on the matter (Safari, WebKit/Gtk, Firefox, Opera), we can sure hope we’ll see less flash and more pure video in the next years.
Mon status Facebook
