Planet WebKit

A QtWebKit KPart is no answer for a KDE browser

2009-07-01T20:13:12+00:00

Disclaimer: I have no desire to re-ignite KHTML vs WebKit arguments. Rather, the purpose of this blog post is to hopefully enlighten a technical question.

Over the last few months I've heard many KDE developers in various forums bemoan the lack of a working and stable WebKit KPart. The motivation behind this complaint seems to be that KDE folk want a WebKit browser option for KDE. Thus the naive solution is to just get the WebKit KDE KPart in shape. Given this motivation... the solution is wrong IMO.

I can speak from some experience here. I've been working on QtWebKit for quite awhile and have also worked - in the past - on the WebKit KPart plus Konqueror integration that Simon started. For a time, it was building and running just fine. You could install it and change a configuration file and Konqueror would render using QtWebKit. However, the integration was *far* from complete. Plumbing the sources of Konqueror I learned a nasty secret: Konqueror is highly KHTML API specific. Konqueror has deep integration with KHTML that goes far above and beyond the KPart API. Creating a QtWebKit KPart is woefully insufficient for the purpose of providing anything more than a basic HTML viewer.

A simple HTML viewer is no where close to a fully modern desktop browser.

This all makes sense if you stop to think about the history of Konqueror. Konqueror is a generic desktop shell. It is designed to allow basic viewing of various documents in various formats. Of course, it has become much, much, more than that. And the key to this growth of features is Konqueror's steady adoption of API's above and beyond the generic KPart API.

Which brings me to my point: if parts of the KDE community truly want a modern browser based on QtWebKit they'd best be looking at solutions beyond Konqueror. Otherwise you are left with two hacky solutions: make a QtWebKit KPart that is API compatible with KHTMLPart OR migrate Konqueror source to make it less dependent on KHTMLPart. The former is not going to be fun as the KHTMLPart API is not refined or polished and highly KHTML specific. The latter can only be accomplished with a lot of work set aside for refactoring or through nasty '#ifdef KHTML callThisWay() #else callThatWay();'

Both of these solutions are sub-optimal in my opinion.

Transparent QWebView (or QWebPage)

2009-06-29T23:01:44+00:00

If you use QWebView, do you know how make its background to be translucent? Apparently, the trick is not so well known, hence I decide to share it here.

Basically it boils down the following code snippet:

QPalette palette = view->palette(); palette.setBrush(QPalette::Base, Qt::transparent); view->page()->setPalette(palette); view->setAttribute(Qt::WA_OpaquePaintEvent, false);

The first three lines set a new transparent brush for the page. This is necessary so that all the painting is blended properly. The last one ensures that the web view is not opaque, i.e. it does not paint all the pixels contained in its rectangle. Opaque paint event for QWebView is the default, most of the time you want to have a web page with typical normal background color, either set by the web page or something you specify as the fallback color.

If you combine QWebView see-through background with top-level widget opacity feature (see what Samuel wrote about this some time ago), you will get something like the following screenshot (the wallpaper image is Soft Green, from Valient Gough). Neat, isn’t it? Note that of course it requires a window system which supports composition, e.g. modern X11 window manager, recent versions of Windows, and so on.

As usual, the code for this short example is available from the git repository, just check the transparentweb subdirectory. Again, I already prepared both the Qt/C++ and Python (via PyQt) versions. Enjoy!

Port of QtWebKit to S60

2009-06-29T15:06:48+00:00

In the recent pre-release of Qt for S60 we have included a build of WebKit that compiles and runs on S60. This pre-release is an important milestone for this porting effort that started about half a year ago. Hence, I would like to briefly highlight a few things about it:

The main work is finding good solutions for quirks in the toolchain. That includes the ARM RVCT compiler and the Metrowerks compiler used by the emulator on Windows, both with their own unique set of challenges.

The team working on this consists of Norbert Leser and Laszlo Gombos from the Nokia Browser Team in Boston as well as Janne Koskinen from Digia and Kristian Amlie from the QtSoftware Team here in Oslo. In addition Ariya wrote the little but super-cool anomaly demo browser, which is included in the Qt/S60 Tower release. The port is still in early stages, but it’s looking quite good already and rather performant.

We’ve been maintaining the patches in separate repositories and we’ve been pushing patches in small steps upstream for a few months now. There’s still a lot to go, but things are progressing. And the result is looking really cool

Helping Out -- Windows License

2009-06-28T20:07:34+00:00

A few people who have found the Windows Cairo WebKit port useful have asked if there was any way to 'donate' to the project or otherwise help out. While the most useful thing anyone can do is to contribute debugging or coding help, there one thing that would really help me out would be if someone could contribute a valid (i.e., Legally transferrable) Windows XP, Windows Vista, or (someday) Windows 7 license so I could do more coding after hours or one weekends.

To help motivate your desire to donate such a license, I present here a photo I took while on vacation this past week. This is a nice example of what awaits you if you rely on Internet Explorer for your web kiosk needs! ;-)

QtWebKit has been ported to S60

2009-06-25T19:00:21+00:00

Alessandro Portale has announced the “Tower” release of the Qt for S60. He writes that “there are three fresh modules: Phonon, QtSql and QtWebkit”, and adds that “QtWebkit on S60 is still considered experimental. However, You should already be able to start developing QtWebKit refined applications for the pocket.”

QtWebKit is a port of the WebKit browser engine to the Qt cross-platform application-development framework, and Qt for S60 is in turn a port of Qt to the Symbian OS, widely used on mobile devices.

Developer Tools for Google Chrome

2009-06-24T16:44:00+00:00

Since the initial launch of Google Chrome back in September we have had the Elements and Resources tabs of WebKit's Inspector available. We are now ready to present Inspector's Scripts and Profiles panels built on top of the V8 engine providing web developers with full-featured Javascript debugger and sample-based profiler in the dev channel release of Google Chrome. We are also re-introducing the Elements and Resources tabs running out of process for better robustness, security and support for the new debugger and profiler setup.

You can invoke new developer tools by selecting "JavaScript console" from the Developer menu (or using Ctrl+Shift+J). For example, running the statistical profiler on the V8 benchmark suite (below screenshot) will give exact information on the actual code execution as the data is generated straight from running the optimized code from V8.

As with the rest of Google Chrome, the developer tools are open source and built upon WebKit and in particular WebKit's Inspector. We would love to get feedback - both in terms of bugs reports and feature requests - on the Chromium public issue tracker. Or even better yet, we would love to get contributions to improving developer tools further in WebKit and Google Chrome.

Posted by Yury Semikhatsky, Software Engineer

Background rationale for layered architecture of WebKit JavaScript engine

2009-06-21T21:19:06+00:00

A recent WebKit bug comment from Gavin Barraclough gives some insights into the rationale for the layered architecture and MacroAssembler used in the current JavaScript engine in WebKit. Some excerpts from that comment:

The abstract code generation layer (MacroAssembler interface down) is layered like a traditional compiler. In a traditional compiler, it is common to have an assembler layer completely independent of the compiler (often a separate application). The compiler takes a source code file, compiles it, and produces an output file of assembly code.…

Layering the compiler on top of an assembler in this fashion provides a number of benefits. For the compiler developer, layering the compiler on the assembler separates the instruction selection from the minutiae of machine instruction encoding. For clients of the compiler providing a well defined language for machine instruction generation is useful if the compiler provides facilities to bypass the higher level language, and directly emit a specific sequence of machine instructions…

The assembler interface within the JIT is designed to closely mimic that of the assembler layer in a traditional compiler…

If that sounds interesting, you can find a lot more details by reading the full text of the comment.

WebKit: Facilitating alternative/experimental implementations of existing features vs. discouraging unnecessary duplication of efforts

2009-06-21T20:57:12+00:00

On the webkit-dev mailing list back in April, there was an interesting thread that Michael Nordman from the Google Chrome team started with a message titled, “AppCache functionality provided by the embedder of webkit” (related to the offline-Web-applications feature in HTML5). Michael begins that message with this paragraph:

I’m working on the app cache for Chrome. We’ve decided to hoist most the functionality provided by the app cache into Chrome’s main browser process, so we won’t be using most of the implementation provided by WebKit. I’d like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated.

Darin Adler responded with some thoughts and a question (to which Michael replied) but the discussion about specifics didn’t go anywhere after that (not on the mailing list at least), because in the next message in the thread, Maciej Stachowiak replied to question the general approach — in fact, to question whether the WebKit trunk should be providing mechanisms to facilitate replacements of parts of its own core code:

It’s been a recurring theme for the Chrome team to request hooks to bypass WebKit functionality and replace it with Chrome-specific code that lives outside the WebKit tree. So far this has been mostly for code developed when Chrome was originally a secret project. While we felt it was best to grandfather in the existing carve-outs, in general I believe this is not the best way to move the WebKit project forward. I would not like to see this pattern replicated for newly developed functionality.

Earlier in the same message, Maciej cites a reason why facilitating the proposed general approach can have a potentially negative side effect:

One downside of this approach is that, if the application cache ever needs to change, it may be necessary to make changes to two separate implementations hosted in different repositories. In addition, quality-of-implementation improvements to one version won’t benefit the other.

[…Continued…]

WebKit destined to get its own content sniffer

2009-06-21T20:54:46+00:00

Web/browser-security maven and coder Adam Barth has been working on implementing a content sniffer in WebKit, based on a content-sniffing algorithm that was originally specified in the HTML5 draft, but that’s now specified as a separate IETF draft that Adam is editing and that’s titled, Content-Type Processing Model.

WebKit applications/ports for particular platforms all currently need to rely on platform-specific content-sniffer code outside of WebKit. There are some reasons why it’s a good idea to do things that way — but there are also some good reasons not to; as Adam notes, doing things that way runs the risk of creating compatibility and security differences among various WebKit ports. So implementing a content-sniffer in WebKit itself will eliminate those differences.

[…Continued…]

WebKit team is implementing HTML datagrid element/API

2009-06-21T13:53:35+00:00

David Hyatt just opened a new WebKit master feature-implementation bug on June 19th: Implement the HTML5 datagrid. His first comment there:

This implementation may end up being very different from what’s in the spec.

The goal is to create a simpler implementation that can help improve the spec.

The <datagrid> element is a new HTML element in the HTML5 draft standard, with a corresponding DOM interface.

Elliotte Rusty Harold did a writeup on datagrid for the IBM developerWorks site a couple years ago, describing it in these terms:

What distinguishes [datagrid] from a regular table is that the user can select rows, columns, and cells; collapse rows, columns, and cells; edit cells; delete rows, columns, and cells; sort the grid; and otherwise interact with the data directly in the browser on the client.

The <datagrid> spec has been updated since the time when that article was published, but at a high-level, the feature remains the pretty much the same as in that description quoted above.

It’s great to see a browser project finally starting to implement <datagrid>, because it’s a great feature that I think a lot of Web authors and Web developers are going to be very glad to have.

Palm released WebCore/WebKit sourcecode for their Palm Pre..

2009-06-19T01:47:23+00:00

My friends just told me that you can get the sourcecode from this place. Or a direct link to their WebCore modifications and WebKit modifications.

Using JavaScriptCore as the QtScript Back-end

2009-06-16T16:52:30+00:00

As Ariya mentioned in one of his previous posts, we’ve been doing some work on using JavaScriptCore (JSC) as the QtScript back-end. The whole idea is that you’ll get the same QtScript API, but with JSC performance. There’s also the prospect of being able to use the QtScript API together with QtWebKit, giving a smooth integration (e.g. having a function similar to QWebFrame::evaluateJavaScript() that returns a QScriptValue rather than a QVariant, and being able to use QScriptValue::call() and QScriptValue::setProperty() and friends; in general, having such API will just make it much easier for the C++ side and JS side to communicate).

The main challenge we’re facing is keeping the QtScript API behave 100% as it does today; it’s not acceptable that the behavior changes just because us speed freaks decide to replace the back-end, of course. The main aid we have in this regard is the set of QtScript autotests; assuming the tests are all-encompassing (which, let’s face it, is hard to guarantee, but let’s pretend…), after completing the back-end swap, all the tests should still pass. Once this goal is reached, some brave soul would step forward, brown paper bag in hand, asserting that except for performance improvements, it’s not possible for the application developer to tell that the QtScript runtime was replaced. OK, so we’ll probably have to do some real-world testing as well.

Work on the back-end had been put on hold for some time due to various other projects, but now we’re slowly getting back in business again. And the best news is that the ongoing work is now out in the open (qtscript-jsc-backend branch)! Now before you start doing the Qt dance, just keep in mind that the branch is not currently in a state where it can be used to run new or existing apps against the back-end, because not all the API and/or behavior is implemented yet. Currently we’re working on bringing it up-to-date with the last few months of changes in WebKit trunk, then we can focus on remaining API. In case you’re interested in helping out hardcore hacker-style, though, there’s an easy recipe that we all follow: Run one of the qscript* autotests, look for failures or asserts that say “Implement me”, and hack on the implementation until the test passes. Test statement by test statement, the compatibility will get there. Happy hacking!

The Chirp Of a Great Framework

2009-06-16T07:45:33+00:00

While planning for Developer Days 2008 I tried to wring something interesting out of my technically starved brain to show off to the crowds of hackers attending. At the time I had just noticed Twitter, a service that seemed to promise the value of Facebook without all the junk - seeing status updates from my friends and the ramblings from people I find interesting or useful from an academic perspective.

I started looking into the Twitter API and found that using Qt’s QNetworkAccessManager I could quickly create something powerful that interoperated with URL API’s. Attempting to be different, I decided that it wouldn’t be cool to create a UI based on traditional QWidgets, and definately too boring to simply browse twitter.com. So, using the Twitter API which returns XML data, QtXmlPattern’s XSLT support and a little bit of creative tinkering with exposing Qt native objects to QtWebKit, I ended up with a useful Twitter client that converted the XML data to UI.

After returning from Developer Days, we enlisted the help of Girish - a(n ex )Troll and Generally Great Guy who helped polish my haphazardly written demo-code into something beautiful and functional - as well as write a completely new example on how to integrate with YouTube! Girish also made some nice screencasts for our Qt 4.5 launch (source follows after);

And now we have finally pushed the two cool examples of QtWebKit that shows how easy and elegant it is to mixing web programming paradigms with native code in Qt! If you want to try it out, play with it, modify it, please head over to the Graphics Dojo and look for twitterview and videofeed. Happy hacking!

DumpRenderTree: Windows Cairo 'Mostly' Good

2009-06-11T18:35:56+00:00

I recently found and corrected the cause of the hated scrolling bug. A question by Jonghoon Kim about the inconsistent use of SetGraphicsMode(bitmapDC, GM_ADVANCED); prompted me to review the handling of graphics context between Windows and Cairo. This led to the discovery that the Windows HDC and the Cairo cairo_t contexts were not being kept in sync in all cases, and so various transformations were being inconsistently applied, resulting in the strange behavior that prompted me to file the bug. Now that the only major rendering discrepancy was resolved, it's time to start solidifying the Cairo port.

I finally got around to updating DumpRenderTree so that it can run the enormous suite of layout tests included with the WebKit sources. I was pretty sure that things would be fairly broken, but I am pretty happy that DumpRenderTree decided that the Windows Cairo build desired a grade of "D".

Here are the test results:

7907.74s total testing time

5598 test cases (54%) succeeded

4597 test cases (44%) had incorrect layout

19 test cases (1%)>

4 test cases (1%)>

409 test cases (4%) had stderr output

Clearly there is a lot of room for improvement. However, as you can see in the screen grab above, many of the differences are a matter of one or two pixels.

I'll probably target the crashes first.

Night-mode in QWebView

2009-06-09T07:01:24+00:00

An interesting feature of a navigation system (so I was told, I don’t own a car) is the so-called "night mode". Basically the display is adjusted so that the text and the map become more readable under low ambient light condition. An easy trick to do this is by inverting the color, just like what Mac OS X can do for the whole desktop.

Thanks to QPainter, it is fairly easy to do that in just a few lines of code. Basically we need to use a proper composition mode. If you think composition modes are like black magic, here is a chance to understand a bit of it. As you read the documentation on QPainter::CompositionMode_Difference or CompositionMode_Exclusion, you will find that Painting with white inverts the destination color. Voila! That is exactly the cheating path that we have to use.

The super-short example for color inversion is in the Graphics Dojo repository under the webnightmode directory (available for both Qt/C++ and PyQt). Although the trick here is illustrated for QWebView, of course it is suitable for other widgets, too (see Henrik’s yesMan example). Note that not every paint engine/device supports QPainter::CompositionMode_Difference, hence why in the code I force the use of raster graphics system under X11.

Note that an actual implementation of a night-mode feature is likely more complicated than just a color inversion method (feel free to suggest or brainstorm the ideas for such an algorithm). The overall brightness and constrast should be taken into account. Likely this requires an adventure in the non-RGB color space, something that is outside the scope of this example. Most of the cases however, you can get away with the discussed trick.

Exercise for the brave readers: use selectors (CSS or jQuery) to find the map element, then invert that element only.

Adam Barth and Dave Levin are now WebKit reviewers

2009-06-08T22:13:26+00:00

Adam has been a long-time contributer of security fixes. Dave comes to us through the Chromium porting effort and has done quite a bit of work on HTML5 Workers as well. Please join me in congratulating Adam and Dave on their reviewer status!

CFLite Corrections, Web Inspector

2009-06-08T17:36:04+00:00

Apple recently released an update of the CoreFoundation sources to their Open Source website, which prompted me to take a pass over the OpenCFLite project to merge the (minor) bits of new code. While doing so, I decided to track down the cause of the bundle loading failure which was preventing WebKit from loading resources from the bundle.

The problem turned out to be due to an incorrect file access method (it turns out that you have to pass the FILE_FLAG_BACKUP_SEMANTICS flag to CreateFile if you want to get a handle to a directory. If you just ask for general permissions you get an "Access Denied" error.)

Lo and behold, once this bug was corrected, CFLite.dll began happily loading WebKit resources which caused the myriad of context menu options to suddenly start working.

The benefit? The AWESOME WEB INSPECTOR is now live and functional! The attached screenshot shows what this looks like under the Windows Cairo build. Not too shabby! :-)

I've updated the requirements.zip file with the revised CFLite.dll.

Taking over memprof

2009-06-08T08:50:40+00:00

Where did all my memory go? Who is allocating it, how much is being allocated? From where were theses QImages allocated? valgrind provides an accurate leak checker, but for a running application you might want to know about allocations and browse through them and don't take the performance hit of valgrind (e.g with massif).

There is an easy way to answer these questions, use memprof. memprof used to be a GNOME application, it was unmaintained, the website was gone from the net, but this tool is just way too good to just drop out of the net. After trying to reach the maintainer twice I decided to adopt the orphaned thing.

Check the application out, it is great, it helps me to get an overview of memory allocations for WebKit/GTK+...

QWebView snap-scrolling

2009-06-06T08:33:14+00:00

When you develop a web browser for a mobile platform, a D-pad or a mini trackball is usually the main in-page navigation input. In some browsers, going "down" scrolls the whole web page or jumps to the nearest (sensible) hyperlink. There is an interesting observation here. As you scroll to read e.g. a news site, your eyes are locked to the topmost part of the browser. Hence, a scrolling system that avoids "slicing" the content right at the top of the view will be useful. Your eyes are not distracted because it is easier to locate the "next-to-read" spot after the page scrolls.

If the above paragraph is not easy to understand, consider the following screenshot. Both windows show the mobile version of BBC News, after scrolling (I pressed the down arrow nine times). On the right side, the image is cut. On the left side however, the image is positioned so that it will be aligned properly. In fact, if I continue pressing down arrow key many times until I reach the section where there is no image anymore, it always scrolls and snaps each text line, which is very convenient as you read the text.

The example for doing this snap-scrolling is in the Graphics Dojo repository under the snapscroll directory (available for both Qt/C++ and PyQt). To keep the example as simple as possible, I implement the snapping when down arrow key is only. Ideally, you might want to handle e.g. the up arrow, as well as page up and page down. Furthermore, the snap threshold constant actually should be font size dependent to ensure smooth scrolling. If you try the code, sometimes it fails because it snaps only in one direction. If you really prefer the "magnet behavior" consider adding some intelligence to snap in both directions.

The code also shows how to find out the bounding boxes (of the DOM elements) in a particular area of interest QWebFrame::hitTestContent() (in Qt 4.6 we will have the full QWebElement solution for this). The code proves, it is sufficient (at least for this scrolling purpose) to check for a hit in several sample points in that area. Beside, if a 3×3 pixels image escapes our detection and will not be snapped, how does it matter anyway?

Happy snapping!

Web Developers: Keeping Up With Google Chrome

2009-06-03T23:57:00+00:00

Google Chrome is moving fast. Version 2.0 was stabilized just six months after 1.0, and auto-updates have ensured that nearly all users are using the newest version of the browser within days of a release. As a web developer, it can be a bit daunting that the browser version changes so fast: What if the new version breaks something? How can I be prepared for changes that will affect my sites?

To answer these questions, it's helpful to know how Google Chrome releases are made, the relationship between "dev," "beta," and "stable" update channels, and how you can test new versions. In this post, we'll be expanding on Mark Larson's earlier explanation of the update channel system.

Stable channel. As Mark outlines, the Stable channel is, well, stable. As a web developer, that means that as long as the major version — the "2" in "version 2.0.181.1" — doesn't change, you can count on Stable channel builds to use the same versions of WebKit (CSS, layout, etc.), V8 (JavaScript), and other components that might affect how a page loads or renders. Stable updates between major version releases are generally focused on addressing security issues, fixing egregious bugs, and improving stability. The big developer-facing bits of the browser won't change on the Stable channel until the next major version is released, and you can always preview upcoming changes using the Beta channel.
Beta channel. As a web developer, being on the Beta channel will ensure that you can test your sites with the next version of Google Chrome's rendering behavior before it's sent to the Stable channel and into the hands of most users. Whenever a major version lands in the Beta channel, the versions of WebKit, V8, networking, and the other systems that affect how web pages load and render generally become fixed. These versions may change during the major version's beta cycle, but changes are usually incremental fixes to help stabilize a feature rather than changes in behavior. New versions of WebKit may be introduced during a beta period, but those versions are always accompanied by a new build number (e.g. 2.0.169.xx vs. 2.0.172.xx) and are unlikely to differ drastically. As this major version moves closer to a stable release, these kinds of changes become more and more infrequent. Since Google Chrome development moves so quickly, you should stay on the Beta channel to catch compatibility issues ahead of time.
Dev channel. The Dev channel is where the sausage gets made. Dev releases happen frequently, and they track what's happening upstream in WebKit, V8, and other relevant systems very closely. This means that changes that might affect rendering, performance, and layout are likely to occur on the Dev channel on a regular basis. We don't recommend that you install the Dev channel if you're looking to maintain site compatibility, since tracking breaking changes as they happen can be a major headache. You should be able to spot any problems early enough via the Beta channel.

Users are on the Stable channel by default. To get onto the Beta or Dev channel, follow these instructions. Once you change to a less stable channel, e.g. from Stable to Dev, there isn't a supported "downgrade" path. If you change from the less stable channel back to a more stable one, Google Chrome will simply stop updating until your new channel "catches up" with the installed build. To force an immediate downgrade, uninstall and reinstall using an appropriate installer. This may occasionally cause errors when your more stable (older) version tries to read the newer user data left over from the previous installation.

Once you have a copy of Google Chrome, you can test your site's compatibility. Google Doctype has a helpful FAQ on best practices for Google Chrome compatibility. In short, prefer object detection over userAgent string parsing; don't rely on pixel-accurate font and element sizes; declare your pages' encodings correctly; double check <object> and <embed> parameters; check for illegal markup; and avoid browser-specific CSS.

The Chromium and WebKit teams work hard to ensure compatibility with websites. If after reading the above you discover browser problems, please don't hesitate to file a bug. If a particular problem with your site occurs in both Google Chrome and a corresponding version of Safari, it may be due to a WebKit issue, which you can file in the WebKit bug tracker. If the problem only happens in Google Chrome, log an issue in the Chromium bug tracker.

Posted by Alex Russell, Software Engineer

Weather applet (again)

2009-06-02T07:25:13+00:00

For any widget system, be it KDE4 Plasma, Mac OS X Dashboard, Yahoo! Widgets, Opera Widget, Google Gadgets, Microsoft Gadgets, and so on, weather applet is usually the typical example (beside a digital clock, an analog clock, or other variants of the clock). What is shown here is yet another little weather info tool, built using QtWebKit.

The idea came up when the other day I presented a challenge to myself: what is the shortest possible code that shows the weather, along with the forecasts for the next few days, for any places in the world? Usually this involves a lot of thinking. Thanks to Google however, the solution came instantly (avid Google users know this by heart). Hint: see the result of searching for "Weather in Oslo".

By smartly (some people call it cheating, though) combining this powerful Google service and a web rendering engine, the solution magically appears. Or rather it should not. Because by using magic, I will be unfair to my fellow (poor) software engineers, I decided to fire my Qt Creator and implemented the answer to that challenge the hard way, i.e. by actually doing it. The screenshot first:

The logic of the program is rather simple. Just loads the proper URL corresponding to the search for the weather, as if you would have typed in manually in your favorite web browser. After the web page shows up, find the DOM element that represents that information snippet (we are not interested in the search results lists), this is done using little jQuery-based JavaScript code. The web page is rendered to a pixmap, only the region of that DOM element is painted, and then the pixmap is shown.

The code is just one git clone (or git pull) away from the Graphics Dojo repository (yes, we are also moving to Gitorious). Check the subdirectory named gweather. You need Qt at least version 4.5.

As healthy exercises for the readers, try the following things. Implement an auto-reload feature (be gentle, no need to refresh the page every 5 minutes). In addition, add a possibility to change the location or city. Remember, magic is not allowed.

Recent WebKit Updates

2009-06-01T15:12:13+00:00

I've beaten back the recent bit-rot that is endemic in tracking the WebKit project. This project moves so fast that if you don't stay on top of things it rapidly leaves you behind!

Recent updates now provide proper support for synthetic bold/oblique fonts, as well as using more of the Chromium team's image decoders. I also corrected various build settings that were causing the Cairo build to attempt to link against old ICU libraries.

The never-ending patch is now down to just slightly over 2 KB. Once I get the printing stuff sorted out this patch should no longer be needed.

Next week I should get the sample JavaScript example application working. This little app will probably start linking against the new JavaScriptCore.dll, since WebKit is now broken into two DLL's to simplify access to the core JavaScript routines.

CallJS Updated

2009-06-01T15:12:01+00:00

I've updated the CallJS sample project with current WebKit binaries.

* Now uses the WebKit COM API call "WebKitCreateInstance", which greatly simplifies using WebKit. No more having to figure out the right incantation to get the manifest files built properly.
* Cleaned up some of the MFC code.
* Updated to current ICU and other support files.

Enjoy!

My first patch to WebKitGTK+ committed!

2009-06-01T03:19:10+00:00

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!

Epiphany/WebKitGTK+ in Debian unstable

2009-05-19T03:29:42+00:00

I have prepared an epiphany-webkit source package some time ago, and it has finally got out of NEW, thanks to the work Ganeff did this weekend on processing the queue =).

The good thing about those packages is I have patched them heavily to allow for easy parallel installation with Epiphany/Gecko, so you don’t need to give up your current browser to experiment and test Epiphany with the WebKitGTK+ backend. The gconf tree used for this package is /apps/epiphany-webkit, separate from the normal /apps/epiphany, for extra safety, but notice that your ~/.gnome2/epiphany will be shared between the Gecko and WebKit versions, even though the files used by each of them are different most of the time.

Go ahead and install the epiphany-webkit package, and have fun. Notice that if you have an already running session of Epiphany/Gecko, running epiphany-webkit will not be enough to launch Epiphany/Webkit, since Epiphany will just request that a new window be opened through D-Bus. The easiest way to test, if you just want a quick peek, is to run epiphany-webkit -p; this will run a ‘private’ instance of Epiphany/WebKit, which doesn’t touch your history, bookmarks, and passwords.

If you are feeling adventurous and want to make Epiphany/WebKit your default Epiphany you can do so using the following command, and selecting epiphany-webkit:

# update-alternatives --config epiphany-browser

WebKitGTK+ 1.1.7!

2009-05-15T00:27:50+00:00

So WebKitGTK+ 1.1.7 is here. JIT is finally enabled for x86-64 on Linux! Yay! Go get it!. I am hoping for 1.1.8 we will have serious improvements on what we have landed recently, and on the Media Player. So, stay tuned =D. It looks more and more like we will have a good release for GNOME 2.28.

Jan Michael Alonzo is now a WebKit Reviewer

2009-05-13T19:46:36+00:00

Jan has been around for a very long time now, and has contributed lots of patches to the GTK+ port of WebKit. He’s worked tirelessly on the build system, and on keeping the port compilable. He has also done important work on the testing infra-structure, and contributed sizable chunks of API. Please join me in congratulating Jan on his reviewer status!

Scrolling in GTK+ and WebKit/GTK+

2009-05-10T19:40:27+00:00

Model/View GtkAdjustment and GtkScrollbar

The GtkAdjustment is probably best described as a model for scrolling. It has several properties, e.g. the current position (value), the lower and upper possibilities, and the size increments. The GtkScrollbar is operating on top of a GtkAdjustment. It is responsible for taking user events and painting. When scrolling it will look at the lower and upper properties, it will update the value in case of something is happening.

WebCore::Scrollbar in WebCore

The Scrollbar is created by the Scrollbar::createNativeScrollbar "factory". For many platforms the painting/theming and behaviour is entriely done within that class. For GTK+ we will use a GtkScrollbar, this widget happens to not have its own GdkWindow which makes painting a bit more easy, we will just forward the original expose event and let it draw as well (from ScrollbarGtk::paint). WebCore::Scrollbar in WebCore are used in two places. One prominent one is the WebCore::ScrollView which is the base class of the WebCore::FrameView and will be used to enable people to scroll on their content in horizontal and vertical direction, the other big user are scrollable div's (we have a manual test in WebCore/manual-tests/gtk/ to test positioning of these scrollbars).

Scrolling on GtkWidget

The scrolling starts quite innocently with the description of gtk_widget_set_scroll_adjustments. In case of WebKitWebView in WebKit/GTK+ we do want to support scrolling so we need to return TRUE... but how. If you take a look at the class structure of GtkWidget there is a GObject signal identifier you will have to set with the signal you have created. This is done in the WebKitWebView class init and we will remember and use the GtkAdjustment, e.g. set by a GtkScrolledWindow, in the WebCore::ScrollView (base of WebCore::FrameView class). The usage of GtkAdjustment allows to have different means of scrolling, e.g. by fingers on a touchscreen, or by a wheel... the representation of the scroll concept will change, the implementation not...

The problem of mainFrame and subframes

So far we will most of the times only have external GtkAdjustment set on the mainFrame that is embedded in something like a GtkScrolledWindow but there are pages that will create a frameset and you will have subframes that require scrolling (my test case here is Google Images). What we are ending up with is having a WebCore::FrameView with GtkAdjustments set from the WebKitWebView and some WebCore::FrameView without GtkAdjustments set at all. On cases without a GtkAdjustment, there is no one that will place a GtkScrollbar (and resize the WebKitWebView to be next to it), so the WebCore::ScrollView will create a ScrollbarGtk to handle this job. This creates the siutation that one WebCore::FrameView class will or will not have a Scrollbar (and manage its size...).

The current solution

When we have a GtkAdjustment set in the WebCore::ScrollView do not think about scrollbars, the need of them, the positioning of them at all. Simply update the properties including the current value, the visibleWidth and contentWidth. The upside is we have a GtkWidget that is working like a GtkWidget and can be embedded into a GtkScrolledWindow or a MokoFingerScroll (back in the better days). The downside of this include that we have more platform specific code and that we will not send onscroll events... due not going through ScollbarClient::valueChanged....

The new solution

Wrap the GtkAdjustment we get set into a ScrollbarGtk but do not create a GtkScrollbar. This should create a WebCore::Widget with WebCore::Widget::platformWidget() returning zero and this should set the width() and height() of this Scrollbar to zero meaning that the ScrollView calculation (e.g. updating visibleWidth/visibleHeight) is not negatively influenced, we can kill some more #ifdef PLATFORM(GTK) from WebCore::ScrollView and that we properly send onscroll events as all scrolling is going through the WebCore::Scrollbar code path, like with every other port. For having navigation working we must be sure to reset the GtkAdjustment, due the nature of the FrameView this is best done when creating the ScrollBar... The progress of this can be tracked in bug #25646.

FrameView and navigation

2009-05-10T19:04:05+00:00

Visiting a site can have certain changes on a FrameView that will not be undone when leaving it. The most prominent example is a fixed background (by CSS) which will disable using blit on scrolling. There might be different things as well. Another one would be the PageCache and navigation to pages in it. The result is that for every page navigation you will create a new FrameView. For most/all ports this is done in FrameLoaderClient::transitionToCommittedForNewPage(). There is even a convience method shared between most ports in the form of Frame::createView.

From an API point of view this means that there is one WebKitWebView (in terms of Gtk+) and this WebKitWebView has one WebCore::Page and this page has exactly one WebCore::Frame the so called mainFrame but throughout the lifetime of WebKitWebView there will be multiple instances of FrameView's setup on the WebCore::Frame mainFrame. This also means that there are times were multiple WebCore::FrameView instances are around but only one should be active at a time.

For WebKit/GTK+ we will need to make sure that all the state of a WebKitWebView is transferred/set to the WebCore::FrameView when it gets created and ever change to a WebKitWebView gets forwarded to it. The most prominet state information are colors and GtkAdjustment (another posting). I think Gustavo is also about to introduce Scrollbar policies soon.

Embedding a GtkWidget into a HTML page

2009-05-08T06:46:27+00:00

In the last few days I have suprisingly (actually not, it comes natural when resigning from a job) more time to do stuff that I really want to do. For the last months my webkit involvement has been mostly been reviewing patches created by other people but now I have done something I wanted to add for quite a long time...

I think one of the benefits of having a native web renderer widget in the toolkit is the integration that is possible. You can embed it into other native widgets and you should be able to embed native widgets into the web renderer. I have been working on the second part and the result can be seein in this bug. The attached example is putting the Gtk Scribble example into every plugin.

In the arora web browser this feature is used to implement ClickToFlash and I plan to still this idea too.

Chromium Tech Talks

2009-04-30T00:55:00+00:00

Since starting work at Google, I've formed a deep appreciation for the number of high quality talks we have access to here (both technical and not). Reading code and documentation is pretty much unavoidable when you're a developer, but you really can't beat hearing directly from the expert's mouth on topics that you're interested in.

Last Wednesday, 5 Chromium experts gave mini tech talks on subjects ranging from the network stack to hacking on WebKit. Armed with 2 video cameras, a microphone, and a whiteboard, we did the best we could to capture these talks and make them available to Chromium developers around the world. Whether you're a seasoned Chromium contributor or just getting started, I think these videos have a lot to offer.

Here's a rundown of the videos:

Darin Fisher talking about Chromium's multi-process architecture

Brett Wilson talking about the various layers of Chromium

Dimitri Glazkov talking about hacking on WebKit

Ben Goodger talking about Views (and how to write good tests for them)

Wan-Teh Chang and Eric Roman talking about Chromium's network stack (and its history)

I hope these are just the first of many tech talks we can offer to you, the Chromium community.

Posted by Jeremy Orlow, Software Engineer

WebKitGTK+ 1.1.6, and on patch reviewing

2009-04-29T21:09:43+00:00

This time, I won’t bother too much with release announcement. Xan has done that job for us =D. The good news that preceeded this release by about a week is that now both me and Xan are reviewers for the GTK+ port, so we are able to approve patches, too, along with the already existing reviewers. This may help our port move forward more quickly. If you think your patch is an easy review, or urgent, do catch us on IRC, and let us know, since our port has quite a backlog, and it may be sometime before our scanning of the list catches your entry =).

Thanks to everyone who contributed to this release. I am sure there are many rough edges to sharpen on the new features, so come test and report bugs, (and provide patches if possible =)) please!

Two releases for the price of one

2009-04-29T12:53:07+00:00

I didn't blog about the 1.1.5 release (although Gustavo did, much better than I do as usual), so now that 1.1.6 is out I'll make a 2x1 post with the highlights. gtk-doc support was integrated into the build system. There's still a few rough edges, but hopefully it won't be too ...

WebKit's week - #8

2009-04-23T14:30:00+00:00

French version

After four months without news, I'll try to be more regular. Let's hope my new organisation will help.

Changes of the week

Everything mentioned below should work with the latest nightly available at the moment (42662).

6 parallel connections (42457, 42559)

With this commit, WebKit can now use 6 parallel connections per domain, previously 4. The number of parallel connections is important to download as fast as possible the resources of a web page. WebKit is now behaving like latest versions of IE, Firefox or Chrome. Opera uses 8 connections per domain. To test this, you'll have to wait for a future version of the CFNetwork library.

function.displayName (42478)

You can create anonymous function in JavaScript. They are very useful but the drawback is they also appear anonymous in the profiler. This make the interpretation of the results pretty hard. Now, you can give a name to those functions and it will be used in the profiler.

Yarr! (42481)

Yarr! (Yet Another Regex Runtime) is, as it suggests, a new Regex Runtime. It is disabled by default for some reasons like being incomplete at the moment but said to be faster than the old one. Hoperfully, we'll have more news when he'll be live.

XMLHttpRequest withCredentials (42483)

This is a new feature from the XMLHttpRequest Level 2 spec. With the withCredentials attribute, you can define whether or not you wanna send the cookies and HTTP authentication data when using a cross domain XHR. Like the number of parallel connections, we need a new version of CFNetwork to test this.

Array.reduce and Array.reduceRight (42563, 42570)

These are two new methods define by ECMAScript 5. You are invited to read the documentation on the Mozilla developer center.

SQL is read only with private browsing (42616)

When using the private browsing mode (aka porn mode), the web database is no longer writeable. Inserts, updates, deletes are no longer available. This way, the website can't record stuff while in a private session.

Implementation of the played attribute (42619)

The new video element has a played attribute which give info about what part of the video has been played. You got access to a TimeRanges object.

This is everything for this week. Of course, this is just a selection I've made. If you've noticed any other interesting changes, please let me know. Same thing if I got something wrong.

Xan Lopez and Gustavo Noronha are now WebKit reviewers

2009-04-22T22:10:55+00:00

Over the last six months, Xan Lopez and Gustavo Noronha have been working tirelessly on the GTK+ port of WebKit. They’ve contributed over 150 improvements to WebKit in the form of bug fixes and API improvements, and have played important roles in driving the development of the GTK+ port forward and assisting contributors that are new to the WebKit project. Please join me in congratulating Xan and Gustavo on their reviewer status!

Fourth Annual WebKit Open Source Party

2009-04-17T20:04:51+00:00

WWDC is upon us, and we hope to see you all there! Our party is open to anyone who is interested, free of charge. So if you will be in town or you are already in town, come and meet some cool web developers, WebKit hackers, browser developers, and lots of folks with an interest in cool technology.

Details

Place: Thirsty Bear Restaurant & Brewery (map)
Date: Wednesday, June 10th
Time: 7:30 PM
upcoming.org

jQuery and QWebElement

2009-04-17T10:56:57+00:00

Any tools which can save the developers the cost of headache pills are always valuable. For web development, JavaScript frameworks such as Prototype and jQuery (and many other similar ones) are these valuable tools. Just for doing content manipulation via JavaScript, using jQuery instead of the standard DOM API would save many precious working hours. No wonder they become so popular these days. Nokia packs jQuery for its Web Run Time, Microsoft bundles it with ASP.NET AJAX.

The QtWebKit team at Qt Software often gets the question like "Can I use jQuery in QtWebKit?". Since QtWebKit is just a normal web-rendering engine, of course the answer is "Yes". To get your feet wet quickly for using the deadly combination of QtWebKit and jQuery, continue reading and examine the demo presented in the following explanation.

There are two ways you can jQuerify your HTML content. If you have total control over the content that you want to display (e.g. using QWebView to display help or other rich-text), then you can refer jQuery directly in the HTML, i.e. inserting the proper <script> referring to the jQuery JavaScript code. If you don’t have a control over the content that you want to display (e.g. using QWebView for a web browser), then the best bet is to inject the jQuery JavaScript code. This can be carried out using QWebFrame::evaluateJavaScript. A nice place to do is after the document is fully loaded. The drawback is that you can’t do any manipulation while loading is in progress, but hey, you don’t have a control over the content anyway.

There are also two methods to pass the jQuery JavaScript code. For convenient access, you may want to store it as a file in the resource, thus it will be shipped along with your application. After that, the code can be referred from within QtWebKit using the qrc:/ URL, i.e. <script src="qrc:/jQuery.js">. If your application is pure web-based or an online hybrid C++/web, you can also source the script from e.g. Google AJAX libraries or using the network access manager to retrieve it (see the previous Monster example for similar trick). This means downloading the script at run-time (eating the bandwidth), but then you get the benefit of automatically update (zero-cost deployment). Judge it based on your needs, which trade-off suits you better.

Without further ado, the code is available in Graphics Dojo repository (no time to git-pull? download the gzipped archive), under the directory fancybrowser. You need Qt 4.5 to build the example. It is basically a normal minimalistic web browser with two extra buttons: to toggle the images upside down and to perform several actions, notably to highlight all links and removing certain types of elements.

For a quick glance of what the demo can do, enjoy the following screencast (watch on YouTube or download/view 18 MB Ogg Theora video).

As an example, here is the function to highlight all the links (yes, it is extremely short!):

void highlightAllLinks() {
    QString code = "$('a').each( function () { $(this).css('background-color', 'yellow') } )";
    view->page()->mainFrame()->evaluateJavaScript(code);
}

Imagine if we would have to implement the same function using DOM API.

Careful readers might notice that the rotation is effect is achieved through two cool features implemented in WebKit: CSS Animation and CSS Transform. If you check out the rotateImages() function, it is also as simple as 7 lines of code. Couldn’t be simpler.

So far so good. But then, Qt 4.6 will sport QWebElement, as Tor Arne recently blogged about. Although it is not replacement for jQuery, for most cases this new element API allows a wide range of content manipulation. It is based on the concept of CSS 3 Selectors, whose query language is surprisingly very similar to jQuery. QWebElement was relatively easy to implement, in particular because WebKit supports CSS 3 Selector ~~since some time already~~ (thanks to David Smith for the implementation).

Although 4.6 is still not on the horizon yet, I modified the example demo to be able to use QWebElement when you build it with Qt > 4.5 (thus, after 4.6 will be released sometime in future, come back and recompile the demo). It is of course no magic that the code change is pretty minimal, in fact the implementation is very similar. For example, here is highlightAllLinks() function implemented using QWebElement (compare it to the previous jQuery flavor):

void highlightAllLinks() {
    foreach (QWebElement element, view->page()->mainFrame()->findAllElements("a"))
        element.setStyleProperty("background-color", "yellow");
}

(As you can witness above, we even went so far to implement the necessary iterator, then foreach works flawlessly!)

As an exercise for the reader, implement a new functionality to undo the highlighting of links. For this to work, you need to change the highlighting code to use a new class (in the context of CSS class, not C++ class), instead of just modifying the background color of the link elements. You need to inject the suitable class definition into the stylesheet as well. Removing the highlighting is then as easy as removing the class from each of the link elements.

Happy CSS-Selecting!

WebKitGTK+ 1.1.5

2009-04-16T13:16:48+00:00

So, we are still mostly able to keep our release each two weeks promise. For this release we have two big additions to the ’support’ side of the project: translations support, and gtk-doc support. The former is made of the usual makefile rules used by gettext-enabled projects with a rework to fit in the non-recursive build process of WebKitGTK+. The later is not as well integrated yet, so you have to go manually to WebKit/gtk/docs and type make, but not before editing WebKit/gtk/webkit/webkitprivate.cpp and adding a call to g_thread_init(NULL); to webkit_init(). You get the idea, we need help in polishing this one.

As for code, Xan Lopez has been doing some serious work on accessibility support, using ATK. After the a11y hackfest he landed a number of patches moving forward in this direction. It looks like we will be able to meet the requirements for becoming blessed for use by GNOME. We also got a nice printing API, that allows applications to stop using the nasty hack that would send a print() call through javascript. They are also able to control/monitor the print process, or automate it, so that no print dialog is shown, if they wish.

That’s it, come join the party =D. Now, for 1.1.6, I’m hoping Diego finishes the spelling check patch, and it would be awesome to have Jan’s proper error reporting!

Monster Evolution in Qt: Episode 3 (Revenge of the Cylinders)

2009-04-15T08:46:14+00:00

Seems nobody is interested in free drinks these days. At last that is my impression since not many guesses have been thrown for the title of this episode. Of course, that could also mean that this monster series is really boring anyway.

Whatever the case, here I present you the third and the latest episode of the Monsterwalker family saga. For those who missed the previous two episodes: The QtScript Menace and Attack of the SquirrelFish, I suggest reading them first to get the clue of the context. It’s merely about running Monster Evolution, part of the Chrome Experiments, written by Dean. As I have hinted before, now we make a radical move. After using Qt Script and JavaScriptCore in the first and second episode, respectively, now we are going to use V8, the fast JavaScript engine behind Google Chrome.

Using V8 means that we have to deal with the bindings manually. With Qt Script, we have the luxury of using its built-in Qt integration. Same goes with JavaScriptCore, we have the hook via QWebFrame. For V8, we need to go low-level and invoke the necessary V8 functions ourselves. Fortunately, V8 is already designed with embedding usage in mind.

Can’t wait to see the code? Check out the git repository under cymonster subdirectory. Grab the archive (find the snapshot link) if you do not use git. Make sure to open the README file and follow the instructions there, this is absolutely mandatory as this code requires a working V8 shared library. Don’t be shocked to see that the code is still as short as the previous examples. Despite our use of V8, the book-keeping and binding parts are kept to minimum.

Since V8 is claimed to have a fantastic performance, don’t be surprised if now you will a very fast rotating monster, unlike in the previous episodes. Typically you should easily reach 25 fps in modern machines these days. For the fun of it, the frame rate is capped at 50 fps (I didn’t bother to do it in the previous episodes, it won’t be reachable anyway). On a high-end machine with fast graphics card and running the demo with OpenGL graphics system, a stunning 30 fps is not so uncommon. If you follow this series faithfully and try all these three episodes, care to share the frame rate you got from each of the episodes?

As a side note, the use of OpaquePaintEvent to avoid offscreen buffer (since we stick to SourceOver composition mode all the time) seems to work only on Windows and Linux/X11, the latter often also depends on the composition manager and good graphics driver, or a combination thereof. Thus, I decided to enable the use of offscreen buffer for Mac OS X. You can still enable it by hand on other platforms if you experience the lack of said effect. Mind you, this would cost you few fps, but that is the price you need to pay.

Last but not least, writing this monster series has been the source of fun and learning for me. I hope you enjoy reading it as much as I enjoy preparing it. May the Script be with you!

The final FAQ:

Q: Since V8 is so fast, don’t you want a V8-based Qt Script?
A: No, since JavaScriptCore is still the official JavaScript engine for WebKit. In addition, there are other reasons that I won’t elaborate here (to mention one: lack of a bytecode interpreter for non JIT-supported platforms).

Q: But you use it already in this example?
A: To use V8 is different that to build a full-blown Qt Script implementation using V8. The former is a fun hacking session for one afternoon, the latter is a real engineer project that spans weeks.

Q: Will there be The Monkey Traces Back?
A: Unlikely, I am exhausted.

Postscript: No monsters were harmed in the making of these demos.

Ariya Hidayat is a WebKit reviewer

2009-04-14T21:29:21+00:00

Ariya Hidayat is our newest WebKit reviewer. He has done extensive work in the
Qt port with countless bugfixes, performance improvements and API designs.
Please join me in congratulating Ariya on his reviewer status.

WebKitGTK+ a11y (virtual) hackfest

2009-04-07T16:53:03+00:00

Interested in WebKitGTK+, a11y or both? This Thursday (April 9th 2009), from 14:00 UTC onwards, we'll hold a virtual a11y hackfest on #webkit-gtk at irc.freenode.net. Willie Walker from Sun will join us, and we'll try to move forward and set up a plan to fix this last blocker in the ...

QWebElement sees the light, do I hear a booyakasha!?

2009-04-07T15:37:39+00:00

One of the main missing parts of QtWebKit so far has been a proper way to inspect and manipulate the document structure. In JavaScript this is provided by the Document Object Model (DOM) bindings — giving you methods like getElementById(), createElement(), and insertBefore(). These methods were also accessible in Qt 4.4 and 4.5 though QWebFrame::evaluateJavaScript(), but it was hardly a optimal way of working with the document.

The reason a proper API for this was deferred in the earlier versions of QtWebKit was because we wanted to provide an API that was not only powerful, but also easy to use. That left out using QDom, or a similar exhaustive API, as customer feedback has shown that writing code on that level can be both tedious and error prone.

Consider the following snippet:

QDomElement docElem = doc.documentElement();

QDomElement root = docElem.firstChildElement("database");
QDomElement entry = root.firstChildElement("entry");
for (; !entry.isNull(); entry = entry.nextSiblingElement("entry")) {
	QDomElement data = entry.firstChildElement("data");
	for (; !data.isNull(); data = data.nextSiblingElement("data")) {
		QDomAttr attribute = data.attributeNode("format");
		if (!attribute.isNull() && attribute.value() == "human") {
			cout   "Data:"  data.text()  endl;
		}
	}
}

Traversing the DOM like this quickly becomes hairy. The same pattern can be found in JavaScript code: using getElementById(), traversing children, looking for a element of a certain type, etc.

Another typical use case is manipulation, where you would do something like:

QDomElement foo = doc.getElementById("foo");
QDomElement elem = doc.createElement("img");
elem.setAttribute("src", "myimage.png");
foo.parent().insertAfter(elem, foo);

Remember to keep your tongue straight when building that insertAfter() statement!

Now some of you are probably jumping on your chairs now, screaming “this is not how you would do it in JavaScript!”. And you’re right, the JavaScript world has found a way to shield off the above annoyances: wrapper libraries like jQuery and Prototype.

Taking inspiration from these libraries we did a one-day prototyping/hacking session back in November, and the results were promising. We also asked customers what they really meant when they were asking for a DOM API, and it turned out that the goal was to inspect and manipulate the DOM, but not necessarily though a one-to-one mapping of the API provided by the DOM specification. Last week we managed to reserve some cycles to continue the work, and we’re now ready for some feedback.

So how does the new shiny QtWebKit DOM API look? There’s two classes: QWebElement and QWebElementSelection.The former wraps a DOM Element, and has methods for manipulation and traversal. The latter is just a list of QWebElements, which can be iterated and extended. The frosting lies in the way elements are selected: using CSS3 selector syntax (similar to jQuery). The implementation of the selectors is already part of WebKit, so we’re basically building on a tried and tested code base.

Using the two snippets above as examples, they would become:

QWebElement document = mainFrame.documentElement();
foreach (QWebElement humanData, document.findAll("database entry data[format='human']") {

	cout   "Data:"  humanData.attribute("format")  endl;
}

and

document.findFirst("#foo").insertAfter("<img src='myimage.png'/>");

That’s a lot easier on my eyes at least.

The initial implementation of the new API is already landed in trunk, so feel free to try it out. You can find the API documentation here, but please note that this is a work in progress, so the API may change.

Oh, and here’s a screenshot of the QtLauncher highlighting all links:

Q: Is the DOM API targeted for Qt 4.6?
A: Yes

Happy hacking!