Planet WebKit

WebKit nightlies support HTML5 noreferrer link relation

2009-11-19T17:18:16+00:00

WebKit nightlies now support the HTML5 noreferrer link relation, a neat little feature that allows web developers to prevent browsers from sending the Referrer: header when navigating either <a> or <area> elements. Just add noreferrer in the rel attribute of a link like so:

<a href="www.example.com" rel="noreferrer">noreferrer!</a>

When example.com receives the HTTP request generated by clicking this link, the HTTP Referer field will be empty, as if the user had navigated from about:blank.

When rel=”noreferrer” is used in conjunction with target=”_blank”, WebKit will also set the window.opener attribute to null. This usage is interpreted as a request from the web page author that any scripts on the destination page should be run in a new context, even if the destination page would normally be considered to be of the same origin.

The noreferrer link relation is one of many link relations defined in the HTML5 spec, and the first to be implemented in WebKit. We hope it will make life a little easier for web developers who have concerns about user privacy and security.

Updated WebKit SDK (@r51062)

2009-11-18T09:11:19+00:00

I have updated the WebKitSDK to correspond to SVN revision r51062.
Edit: I stupidly wrote "-webkit-block-shadow", when I meant "-webkit-box-shadow". Thanks to Brad K. for catching this!
Major changes in this revision:
* Support for -webkit-box-shadow.
* General support for Canvas and SVG shadows in Cairo.
* New SVG filter effects: feComposite, feDisplacementMap, feGaussianBlur, feMorphology
* Many SVG rendering improvements, including support for SourceAlpha.
* Support for CSS in Text Kerning and ligature.
* Ability to specify the number of visible lines in -webkit-line-clamp.
* Implement DOM Level 3 composition events.
* Implement CSSOM Range.getClientRects/getBoundingClientRect.
* @import now works in user stylesheets.
* Protect Canvas methods from NaN and Infinity.
* Web Inspector improvements (see this blog entry for details), but many cool new features!
* Some support for -webkit-color-correction (needs further testing on this platform).
* JavaScript engine speed-ups.
* Initial <ruby> support (see this blog entry for details)
* Accessibility improvements.

Clearly this is a significant amount of new logic, so there may be some regressions. Please let me know if you encounter any problems with this new version.

Unfortunately I have not been able to complete work on 3D CSS or WebGL, but stay tuned!

WebKit-Box-Shadows At Last!

2009-11-16T13:10:46+00:00

With the landing of ~~Bug 26102~~, all Cairo ports of WebKit can now enjoy full webkit-box-shadow support. Even the multi-line wrapped bordered text show shadows, and the geometric primitives in the "border-radius-big.html" test work.

It took a long time, but the results are definitely worth it!

WebKit's week - #10

2009-11-15T22:37:00+00:00

Week from May 25 to June 7 (before r44490). To test those changes, you'll need a WebKit nightly.

Smarter border-radius (44235)

You all know border-radius. And you enjoy using it. Before this change, if the radius was longer than some metrics (eg. half the width of the element), then it's set to zero and there are no rounded corners. Since then, WebKit follow the latest rules of the spec and will reduce the radius to the max possible value.

Multiple corrections according to specs (44293, 44298, 44301, 44302, 44360, 44475, 44481)

A lot of events weren't dispatched to the window object, unlike what the spec says. Zou, fixed. In addition, some storage events needed a storageArea event giving access to the modified storage area. Those are small but necessary fixes.

Locking the anchor in view while loading

Between the moment when a page starts to render and when it's fully loaded, a lot of resources can modify the layout of a page. Therefore, the position of an anchor can change. Before this change, the browser stayed at the initial position of the anchor. Now, if the user doesn't scroll, the anchor will stay in the view.

Web Inspector's panel activation

The Resources, Network and Profiles panels all have an activation page. This activation page are here to not affect the performances of the pages when they are not needed.

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.

Functioning Box-Shadow

2009-11-15T22:31:11+00:00

It's taken a couple of weeks to get everything put together and landed in the archive, but tonight I finally got webkit-box-shadow functioning in the Cairo build.

This original work was done by Dirk Schulze, who put together most of the shadow logic. There were a few dark corners that had to be examined and resolved before the feature worked properly.

The main problem boiled down to a very simple coding error:


===================================================================
--- GraphicsContextCairo.cpp    (revision 50998)
+++ GraphicsContextCairo.cpp    (working copy)
@@ -1113,7 +1155,7 @@
     cairo_t* cr = m_data->cr;
     double x1, y1, x2, y2;
     cairo_clip_extents(cr, &x1, &y1, &x2, &y2);
-    cairo_rectangle(cr, x1, x2, x2 - x1, y2 - y1);
+    cairo_rectangle(cr, x1, y1, x2 - x1, y2 - y1);
     cairo_rectangle(cr, r.x(), r.y(), r.width(), r.height());
     cairo_fill_rule_t savedFillRule = cairo_get_fill_rule(cr);
     cairo_set_fill_rule(cr, CAIRO_FILL_RULE_EVEN_ODD);

The clipping rectangle was being computed with the right-hand x-position of the current clipping bounds, rather than the y-position per the signature. This was causing the wrong regions of the screen to be clipped out, yielding bizarrely inverted shadow effects (see my last post for an example.)

The final results look pretty good. They generally match the reference implementation (Safari), at least as closely as WinCairo does in other respects (e.g., fonts), as shown in the following overlay:

Once this patch lands, both the Linux and Windows builds of WebKit (Cairo) should begin enjoying most of the cool features provided by webkit-box-shadow. There are still several missing bits of functionality:

Shadows on various geometries don't seem to work (see the "border-radius-big.html" test).

Multi-line shadow effects (see the first series in "basic-shadows.html".)

Strangely, this effect works properly when the shadow is inset in the image.

WebKit adds support for the HTML5 <ruby> element

2009-11-13T02:36:47+00:00

If you don’t know what the HTML5 ruby element is, you might want to take a minute to first read the section about the ruby element in the HTML5 specification and/or the Wikipedia article on ruby characters. To quote from the HTML5 description of the ruby element:

The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana.

I give a specific example further down, but for now I want to first say that the really great news about the ruby element is that last week Google Chrome developer Roland Steiner checked in a change (r50495, and see also related bug 28420) that adds ruby support to the trunk of the WebKit source repository, thus making the ruby feature available in WebKit nightlies and Chrome dev-channel releases.

A simple example

The following is a simple example of what you can do with the ruby element; make sure to view it in a recent nightly or dev-channel release. Note that the text is an excerpt from the source of a ruby-annotated online copy of the short story Run, Melos, Run by the writer Osamu Dazai, which I came across by way of Piro’s info page for his XHTML Ruby add-on for Firefox (and which I mention a bit more about further below).

きのうの豪雨で山の水源地は<ruby>氾濫<rp>（</rp>
<rt>はんらん</rt><rp>）</rp></ruby>し、濁流
<ruby>滔々<rp>（</rp><rt>とうとう</rt><rp>）</rp>
</ruby>と下流に 集り、猛勢一挙に橋を破壊し、どうどうと
響きをあげる激流が、<ruby>木葉微塵<rp>（</rp>
<rt>こっぱみじん</rt><rp>）</rp></ruby>に<ruby>橋桁
<rp>（</rp><rt>はしげた</rt><rp>）</rp></ruby>
を跳ね飛ばしていた。

If you don’t happen to have Japanese fonts installed, here’s a screenshot of the source for reference:

Notice that the actual annotative ruby text (which I’ve highlighted in yellow in the source just for the sake of emphasis) is marked up using the rt element as a child of the ruby element, and the text being annotated is the node that’s a previous sibling to that rt content as a child of the ruby element. The final new element in the mix is the rp element, which is simply a way to mark up the annotative ruby text with parenthesis, for graceful fallback in browsers that don’t support ruby.

So here’s the rendered view of that same text:

見よ、前方の川を。きのうの豪雨で山の水源地は氾濫（はんらん）し、濁流滔々（とうとう）と下流に集り、猛勢一挙に橋を破壊し、どうどうと響きをあげる激流が、木葉微塵（こっぱみじん）に橋桁（はしげた）を跳ね飛ばしていた。

And here is a screenshot of how it should look in a recent nightly or dev-channel release:

Notice that the annotative ruby text is displayed above the ruby base it annotates. If you instead view this page in a browser that doesn’t support the ruby feature, you’ll see that the ruby text is just shown inline, in parenthesis following the ruby base it annotates. So the feature falls back gracefully in older browsers.

If you’re not accustomed to reading printed books and magazines and such in Japanese, you may be feeling underwhelmed by the example above. But for authors and developers and content providers in Japan who want to finally be able to use on the Web this very common feature of Japanese page layout from the print world, getting ruby support into WebKit is a huge win, and something to be very excited about.

Support in other browsers

Current versions of Microsoft Internet Explorer also have native support for ruby, and you can also get ruby support in Firefox by installing Piro’s XHTML Ruby add-on (and for more details, see his XHTML ruby add-on info page) — so we are well on the way to seeing the HTML5 ruby feature supported across a range of browsers.

Kenneth Rohde Christiansen is now a WebKit reviewer!

2009-11-11T17:59:05+00:00

Kenneth has been participating in WebKit development since late 2008, when he started the initial EFL port. Since early 2009 he has contributed a great deal on all fronts of the Qt port, including WebCore integration and API. He has also played an important role in making sure the GTK+ and Qt ports work together wherever possible.

Please join me in congratulating Kenneth on his reviewer status!

Compiling WebKitGTK+ on Scratchbox for ARM platform

2009-11-11T14:25:33+00:00

If we would like to build WebKitGTK+ for ARM platform, Scratchbox could be a good choice. In this post I will show, how we can install and setup Scratchbox to build WebKitGTK+. First, we have to install the Scratchbox and its ARM target. Next, we install some libraries to WebKitGTK+.
Let's see how we can do that.

About Dynamic UI, Web-Apps, Performance, and State-Machines

2009-11-09T04:21:31+00:00

Lately I’ve been working on a couple of exciting customer projects, involving HTML5-based UIs on embedded (TV) platforms. Due to the fabulous work some of my colleagues put into QtWebkit and QtDirectFB, and the ongoing work from MIPS Technologies on their Webkit JIT, the paint performance is very good, and Javascript is getting faster and faster.
However, while working on these projects, I’ve ran into a few issues that were not solvable by JIT-accelerated JavaScript or by hardware accelerated painting.

The main problem was that when you write a dynamic UI for a full application, the complexity starts to be difficult to manage. I started by dividing the app to a few HTML pages, but that of course created unacceptable delays when switching between the pages. So I looked online for dynamic web-app solutions. Those include the amazing Javascript libraries Dojo and JQuery. The problem with those is that they manage the complexity by selecting elements with custom-built CSS-like selectors (which are slow) and by modifying the HTML DOM tree in runtime (which is slower).

An alternate way to handle HTML performance is with the HTML5 canvas element (which is nicely accelerated) - the problem is that canvas API is currently too low level, and the widget libraries on top of it are not mature yet, definitely not in time for my customer projects.

So I asked myself: what components are really needed in order to make a dynamic UI?
Looking at the Qt Kinetic project, I need 4 main elements:

Animations
State Machine
Graphic effects
Declarative Syntax

Now HTML and CSS are already a declarative syntax, and CSS3 (supported in webkit) contains all the animations and graphic effects I currently need. The missing element, which is also my personal favorite, is the State Machine.

Why do I keep going on and on about state-machines?
If you think about it, both CSS, HTML, and Qt widgets are optimized to handle complexity in space. State machines, however, are optimized to handle complexity in time. An application can be dynamic only if it’s rich both in space and in time. That’s why to me state-machines are of outmost importance for dynamic UIs.

Enough philosophy, what’s this about?
Now I’ve had the pleasure to work with the SCXML standard in the last year, both by prototyping the Qt-SCXML library (which later helped with the evolution of the Qt State Machine Framework), and by joining the w3c group that defines the SCXML standard.
While working on my latest HTML-based project, I was thinking - what if I could define the flow of my web-app with an SCXML statechart? Wouldn’t that allow for managing the complexity of my web app, without incurring the performance overhead of modifying and re-modifying the DOM?

Introducing Statechartz
So I took the time to write an SCXML library for Javascript. I basically had to copy the SCXML algorithm to Javascript syntax, which took a while, but has already saved me hours of work by having the code of my web-apps cleaner and smaller.
The result can be found at the statechartz branch on the SCXML lab GIT repo., and the demo can be viewed online. Note that the library is currently only tested on webkit-based browsers (QtWebkit/Arora, Safari, Chrome), but porting it to other browsers shouldn’t be too difficult.

Looking a bit at the HTML code of the demo, you’ll notice the following:

<link rel="statechart" href="flow.scxml" />

This is the line that connects an HTML page with an SCXML statechart, defining the page’s flow. The state-machine would start running as soon as the page is loaded.
But hey! rel=”statechart” isn’t standard!

Well, I was surprised to learn that HTML5 allows you to add your own link types, which become legal if you register them in the WHATWG Wiki , which I did; so now <link rel=”statechart” href=”somefile.scxml” /> is completely standard
Though using the link tag would cover most cases, it’s completely optional and the Statechartz library can be used more dynamically, either by loading an SCXML file whenever wanted:

var myStateMachine = Statechartz.loadScxml(someURL);

or by using a dynamic javascript syntax that looks like this:

var myStateMachine;
with (Statechartz) {
  myStateMachine = build(
    State("root",
        Entry(function() { doSomething(); }),
        Parallel("s1",Initial,
             Exit(function()(doSomethingElse(); }),
             Transition(Event("EVENT.QUIT"), Target("exit"))
        ),
        Final("exit")
    )
  );
}

Another thing to look at, is the DOM:

<div id="screen_weather" class="screen">
      <script type="text/javascript" src="..."></script>
</div>
<div id="screen_shopping" class="screen">
    <iframe src="..." height="240" width="320" scrolling="no" style="overflow:hidden" frameborderwidth="0"></iframe>
</div>
<div id="screen_calc" class="screen">...</div>

Even though screen_weather, screen_shopping and screen_calc exist in the DOM to begin with, only one of them is shown at a time. Also, there’s no particular Javascript code that shows and hides them. That’s done by a trick I added to the Statechartz library: the CSS class of the document BODY element changes when the state changes. So, if I’m in a state with ID “calc”, the body would have a CSS class “state_calc”, and now all it takes is adding this to the CSS (it’s a little different in the actual CSS, but I’m trying to make a point):

#screen_calc {
  left: -350px;
  -webkit-transition-duration: 600ms;
  opacity: 0.5;
}
.state_calc #screen_calc {
  left: 0px;
  -webkit-transform: rotate(360deg) scale(1);
  opacity: 1;
}

This code, like states and transitions in Qt 4.6, would animate the opacity and geometry of my calculator screen, and would create an animated transition when the calculator is entered to / exited from.

The Demo, and performance
The

demo that comes with the statechartz library demonstrates 3 uses of the Statechartz library:

Dynamic UIs with states and transitions (switching between the 3 widgets)
Managing UI complexity (e.g. the instructions popup)
Business logic (the calculator ‘engine’)

Note that the demo specifically is too animation-heavy to run well on embedded platforms, and of course webkit could use some more optimizations. but the concepts (don’t mess with the DOM, use Statecharts to manage time) are the same, and are working on other webkit-based projects with a cvery nice performance gain.

The next step on the SCXML path
After this project, SCXML is now supported in 3 implementations: Qt C++ (with scc), QtScript (with QScxml), and web (with Statechartz). The next natural step is a statechart graphical tool (Creator plugin) that can help author SCXML files for all of those 3 implementations. Though it’s not on our roadmap, some of us (including the undersigned) were working on prototypes, and any help from the community would be appreciated!

Links
The code: http://qt.gitorious.org/qt-labs/scxml/trees/statechartz
The live demo (webkit browsers only): http://labs.trolltech.com/blogs/wp-content/uploads/2009/11/demo.html
Video capture of the live demo: http://labs.trolltech.com/blogs/wp-content/uploads/2009/11/statechartz-capture_0001.wmv

Web Inspector Updates

2009-11-04T02:13:28+00:00

A number of exciting new features have been added to the Web Inspector since our last update. Today we would like to highlight some of those features! This post is also available in Japanese (日本語), thanks to Keishi Hattori (服部慶士).

If you would like to play with most of these features you will need to be running a recent WebKit Nightly. Once downloaded make sure that you enable the Web Inspector by checking “Show Develop menu in menu bar” under the Advanced tab in the Preferences.

Editing Element Attributes and Style Properties #

Editing Element Attributes and Style Properties has been made even simpler and more developer friendly. The interfaces for editing attributes and properties now support tabbing to allow you to move between items, and create new items with ease.

Besides tabbing you can also add a new attributes to a node. Start by hovering over the node in the Element’s Tree Hierarchy and after a polite wait a clickable template for a new attribute will appear.

Related Bug Reports: Add Element Attributes, Tabbing, and Improved UI.

Creating and Modifying CSS Rules and Selectors #

A powerful new feature in the Web Inspector allows you create new or modify existing CSS Rules and Selectors. We expect both developers and designers will find this very useful when experimenting with new ideas or tweaking existing designs.

The interface for working with selectors starts with a new Gear Menu in the Styles Sidebar Pane. Select “New Style Rule” and a new section will be created for you, pre-populated with an intelligent selector from the selection in the Elements Tree Hierarchy. Editing selectors is activated by double-clicking. Once again, tabbing will allow you to navigate between selectors and their properties.

When editing selectors there is visual feedback when you create or modify a selector that does not affect the selected node in the Elements Tree Hierarchy. This indicator helps detect errors when making changes.

One more tweak to the Styles Pane is that there is always a section for the selected node’s style attribute. This allows you to easily add style information to the node as you usually would via the Styles Pane instead of editing or creating a “style” attribute. This section is nearly always on top due to how CSS specificity works.

Related Bug Reports: Selectors Support and Move to Gear Menu.

CSS Color Representations #

Colors in the Styles Pane can be shown in any of their possible representations. For simple colors this includes short hex, full hex, rgb, hsl, and potentially a nickname. For advanced colors this includes rgba and hsla. For example the color “white” can be represented as: #FFF, #FFFFFF, rgb(255, 255, 255), hsl(0, 100%, 100%), and white.

You can use the Styles Pane’s Gear Menu to set your preferred representation. However, if you want to cycle through an individual color’s different representations you can do so by clicking on its associated color swatch.

Related Bug Reports: Color Representations, Preference and Gear Menu, and UI Improvement.

DOM Storage #

The Storage Panel (formerly the Databases Panel) now allows you to monitor DOM Storage areas like localStorage and sessionStorage in a familiar datagrid. The DOM Storage datagrid displays live updates so monitoring changes is possible without manually refreshing the view.

Also, the familiar creation and editing techniques apply to the datagrid. To add a new key/value pair just double-click in any open area, or double-click an existing item to start editing. Tabbing works as you would expect.

Related Bug Reports: DOM Storage Support, Live Updates, Create New Items, and Tabbing.

Keyboard Shortcuts #

Keyboard shortcuts are always desired by developers. They can be hard to discover, so here is a complete list and here are the ones that were added recently:

Switch Panels — Command-[ and Command-] on a Mac or Control-[ and Control-] on other platforms.
Delete a Node in the Tree Hierarchy — either Delete or Backspace keys will do the trick.
Quick Edits in the Tree Hierarchy — Hitting Enter or Return on a Node in the Tree enters the editing mode for that type of Node. For a Text Node you will start editing the content. For Element Nodes you start editing the first attribute, or, for convenience, a new attribute will be added for you.

The Scripts Debugger was updated to support some popular keyboard shortcuts:

Continue — F8 or Command-/ on a Mac or Control-/ on other platforms.
Step Over — F10 or Command-’ on a Mac or Control-’ on other platforms.
Step Into — F11 or Command-; on a Mac or Control-; on other platforms.
Step Out — Shift-F11 or Shift-Command-; on a Mac or Shift-Control-; on other platforms.
Next Call Frame — Control-. on all platforms.
Previous Call Frame — Control-, on all platforms.
Evaluate Selection When on a Breakpoint — Shift-Command-E on a Mac or Shift-Control-E on other platforms.

Cookies #

Viewing Cookie information is now possible under the Storage Panel. Supported platforms show all of the cookies and their hidden information for all domains accessed on the inspected page. Cookie information includes the name, value, path, expiration date, http only flag, and secure (https) flag. Supported platforms may also delete cookies.

If your platform doesn’t have full support you aren’t left in the dark. You will still be able to see the keys and values of the cookies that are accessible via JavaScript on the inspected page.

Related Bug Reports: Initial Support, Hidden Data 1 and 2, Cookies for Sub-Resources, and UI Improvements

Event Listeners #

A new Sidebar Pane has been added to the Elements Panel which displays the registered Event Listeners for the selected node. The Event Listeners that are shown for the selected node are in the exact order that they are fired through the Capturing and Bubbling phases. This provides developers with the most accurate and useful information possible.

The user interface shows the registered Event Listeners separated by type. If a node has both “onclick” and “onmouseover” listeners then they will naturally appear in different sections. You can also set your filter preference using the Gear Menu. You can choose to see only the listeners registered on the selected node, or the entire event flow.

We are actively looking for UI improvements in this area. So if you have some ideas or feedback please feel free to let us know on this bug report!

Related Bug Reports: Event Listeners.

Syntax Highlighting #

Syntax highlighting enhances readability, makes debugging code easier, and looks really awesome. The Web Inspector now includes syntax highlighting for JSON and CSS.

CSS Syntax Highlighting even works on the more complex “at-rules” such as @import, @media and @font-face. In addition to supporting the syntax highlighting in the Resources Panel, inline scripts and styles in the Elements Tree Hierarchy are syntax highlighted!

Related Bug Reports: JSON Highlighting, CSS Highlighting, and Inline Highlighting.

Breakpoints and Watch Expressions #

The Script Debugger continues to become more powerful and more useful. We already mentioned the keyboard shortcuts above, but there are plenty of other enhancements.

There is a new Breakpoints Sidebar Pane that allows you to easily monitor and work with your breakpoints across all files without the hassle of searching for them. Each sidebar entry shows the source line and contains a checkbox that allows you to directly enable or disable the breakpoint. Clicking on the entry will jump you directly to the highlighted line in the source file. Finally, deleting a breakpoint has been made easier by clicking the “blue tag” breakpoint indicator. The tag will cycle through its three states of active, inactive, and removed.

A powerful feature added to the debugger is Conditional Breakpoints. Once you have a breakpoint set, right click on the “blue tag” breakpoint indicator and you will get a popup asking for a conditional statement for that breakpoint. Simply provide an expression and the breakpoint will only pause from then on only if the condition is true.

Another new feature in the Debugger is Watch Expressions. In this new Sidebar Pane you can add any number of expressions that evaluate in the global scope normally but in the local scope when paused in the debugger. Once added you get the full Object Properties tree view of the values of each expression. These watch expressions automatically refresh when the debugger pauses. They are also persist across page loads.

Debugging AJAX #

An extremely valuable feature for developers working with AJAX is the ability to view the exact parameters and payload sent on XMLHttpRequests.

In the individual resource view there are new sections for viewing submitted Form Data, Query String Parameters, and Request Payloads when appropriate. You can toggle viewing the information in its unencoded (default) and encoded forms with a double-click.

There is also new section named HTTP Information which contains the Request Method (GET, POST, etc.) and the Status Code (200, 404, etc.). Additionally, it adds a colored dot next to the requested URL to show the status (green for success, orange for redirect, and red for error).

Related Bug Reports: HTTP Status Code and Data, Parameters, and Payload

Resources and Console Scope Bars #

In order to filter through the Resources or Console messages the Web Inspector now sports some familiar Scope Bars. This has proven to be very useful in the Resources Panel for easily viewing all resources of a particular type.

Related Bug Reports: Resources Scope Bar and Console Scope Bars.

Resources Timeline #

The Web Inspector now specifically shows in the timeline when the DOMContentLoaded and Load events fire. This helps clarify the time it takes for pages to load and helps you improve your websites load times.

Related Bug Reports: Show Load Lines

Resources Interactivity #

A couple new features allow you to more directly access individual resources from within the Web Inspector. Instead of copying their URL and opening a new tab manually you can now double-click the Resource in the sidebar to open it directly in a new window. Or, you can drag and drop the resource using HTML5 drag and drop events!

Related Bug Reports: Open Resource Directly and Drag and Drop.

Console Improvements #

Properties in the Web Inspector’s Console are now sorted in a much more natural and useful way. By sorting keys alphanumerically Arrays with greater then 10 elements are much easier to work with.

Another tweak is that collections such as NodeLists and HTMLCollections are now displayed like Arrays. This meaning that their contents are shown directly in the console, no longer requiring any extra boilerplate.

Related Bug Reports: Sorting and NodeLists.

Firebug Command API Improvements #

More improvements have been made to support more of the Firebug Command Line API. The Web Inspector now supports the inspect() function, which can take an Element, Database, or Storage area and automatically jumps to the appropriate Panel with information. Also, the $0-$4 variables contain the current and previous selected nodes from the Elements Tree Hierarchy.

These command line APIs are usable inside the Web Inspector’s Console. To make working with these APIs even easier, they now show up in the Console’s autocompletion.

Related Bug Reports: $# Variables, inspect() Function, and Autocompletion.

How You Can Contribute #

Many of these new features were added by members of the Open Source Community. We would like to encourage you to contribute as well! Since the Web Inspector itself is mostly HTML, JavaScript, and CSS that means that you already have the skills you need to join in! Interested? Play around right now by inspecting the inspector itself!

If you’re interested in contributing and have any questions please stop by the #webkit-inspector IRC channel! As an encouragement to developers, included at the end of each section above are the core bug reports that were involved in bringing each of these features to life.

Finally, if you have ideas for new features, any improvements, or if you’ve stumbled across a bug then please don’t hesitate to create a bug report. This link has pre-populated most of the fields so that you only need to fill out the Summary and Description. As always you should do a quick search through the existing inspector bugs first.

The effect of TCmalloc in the QtWebKit port - stage 2: Memory consumption

2009-10-28T13:18:40+00:00

As I mentioned, there is a reverse of a medal, so now let's see how enabling TCmalloc on the QtWebKit port's JavaScriptCore engine effects memory consumption.

Building QtWebKit on Windows

2009-10-27T12:37:14+00:00

When I tried to build QtWebKit on Windows the first time, I realized it was a more complex task than on Linux. I experimented a lot to make building, testing and WebKit scripts work correctly. I decided that I would fix imperfect scripts and write a blogpost about this topic to relieve WebKit developers sufferings.

More Cairo Shadow Work

2009-10-26T00:28:50+00:00

WebKit Uber-Hacker Dirk Schulze has been hard at work on his SVG (and general graphic) filter modifications in WebKit. It now seems that drop-shadow support will be very doable using the existing Cairo backend. I am still spending a bit of time porting the work over to the Skia backend, but took a break from that to try out a few of Dirks updates, as well as attempting to correct some WebKit bugs manifested by enabling filters under Windows.

As you can see from the first image, Dirk has gotten very nice looking stroke shadows. Likewise, he has gotten proper image masked shadows working, shown in the second image. I'm quite impressed with the facility's ability to generate a correct shadow from the generated gradient. The page shows a few other examples, but these highlight the main idea.

On the Skia front, I've gotten WebCore building, and a partially functioning WebKit build. However there's still a few things I need to reconnect. It looks like there are a few things that live in "platform/graphics/chromium" that might make more sense in "platform/graphics/skia" (namely ImageBufferData.h, and perhaps some of the font and icon handling.) It also seems like the Skia backend is not as fast as the Cairo backend. This is currently a purely subjective observation, and of course neither backend is currently taking advantage of any hardware acceleration (well, actually Cairo probably is). However, the presence of the compositing and 3D transform support in Skia still make this look like a good choice, especially when attempting to address 29813.

Experiments with Cairo Shadows

2009-10-23T19:13:24+00:00

Fellow WebKit hacker Dirk Schulze pointed out to me that the various filter work he was doing would largely provide the functions needed to support box-shadow, and that they might even work on the WinCairo port.

I went ahead and enabled the filter support in WebKit, corrected some build problems caused by the Windows ports' non-use of the filter features until now. I then fired up the resulting binary and tried out the box-shadow support. The screenshot shows the result of this effort -- not so great. The shadows seem to be inverted so that they are cast inside the box. I'm not quite sure what's wrong there!

I also tried out the HTML5 test page he pointed out. As you can see in this second screenshot, the filled areas shadow nicely (pretty much matching what Safari does), but that stroked areas are not shadowed.

Dirk points out that stroke support will be coming, though I'm not sure how quickly that work will be completed.

I'm also enabling the Skia support in WebKit for Windows, and will try these same examples on that build, hopefully this weekend.

WebGL Now Available in WebKit Nightlies

2009-10-19T20:55:20+00:00

Introduction

WebGL is a new standard being worked on in the Khronos consortium. The work done in Khronos is only available to its members, so I can’t show you the spec just yet. But it will become public within the next few months after a review by Khronos members. The good news is that WebGL is now available in WebKit nightlies as of October 4, 2009 (r49073). So if you’re running Leopard or Snow Leopard you can try it out for yourself. WebGL runs in the HTML Canvas element, so it works very similarly to the 2D Canvas capability currently in WebKit.

OpenGL for the Web

OpenGL has been around for ages, so it’s very mature. It can handle all the features of the most advanced graphics cards, but works across a wide variety of hardware. WebGL is based on OpenGL ES 2.0 which is a shader based API.

WebGL is a very low level API, so it’s not for the faint of heart. OpenGL’s shading language, GLSL, is itself an entire programming environment. So doing even simple things in WebGL takes a lot of code. You have to load, compile and link the shaders, setup vertex buffer objects to hold the shapes, and setup the variables to be passed into the shaders. Then you have to do matrix math to animate the shapes. If you want to learn more about all this before continuing, head over to the OpenGL Site for some nice tutorials.

Getting Started

WebGL is really cool! But because it’s new and still under development it isn’t turned on by default. To do that, you need to go into Terminal and type this:

    defaults write com.apple.Safari WebKitWebGLEnabled -bool YES

Once you’ve done that, restart the WebKit nightly build. Then click on the image below. If you see a spinning cube, you have WebGL installed and enabled. If not go back and make sure you have the latest Safari and you typed the above line correctly.

Click to see Spinning Box (requires WebGL)

If you don’t have a nightly build, you can still see WebGL in action here.

A Simple Example

Let’s see how to create the spinning cube above. For the examples and demos here I’ve created a couple of files of JavaScript utilities to help out: one with some general utilities and another with a set of matrix functions. These will let us focus on the different steps needed to use WebGL without worrying about the details.

Like I said, WebGL is built on top of the Canvas Element. So just like you do for a 2D Canvas you start out by getting a CanvasRenderingContext with a call to the getContext method of the Canvas Element, passing the string “webkit-3d” (this is temporary, and will eventually change to “webgl”). The returned object has a set of functions very similar to OpenGL ES 2.0.

Using Shaders

Nothing happen in WebGL without shaders. They take shape data and turn it into pixels on the screen. When using GLSL you define two separate shaders. The vertex shader runs on each corner of every triangle being rendered. Here you transform the points, pass along the texture coordinates and use the normals to compute a lighting factor based on the normals of each triangle. There is a really nice GLSL Tutorial on lighting. GLSL gives you one special variable to store the transformed corner point, gl_Position. The value stored there for each of the corners of a triangle is used to interpolate all the pixels being output. The texture coordinates and lighting factor are passed in varying variables we created for the purpose.

All these values are passed to the fragment shader, which runs on each pixel of every transformed triangle passed in. This is where you get the appropriate pixel from the texture, adjust its lighting, and output the pixel. GLSL gives you a special variable for this, gl_FragColor. Whatever color your store there will be the color of that pixel.

So let’s define the shaders. I’ll use normal script notation here, even though HTML ignores it. It’s a useful way to include GLSL. The contents of the script will be passed as a string to the shaderSource function:

<script id="vshader"type="x-shader/x-vertex">

        uniform mat4 u_modelViewProjMatrix;
        uniform mat4 u_normalMatrix;
        uniform vec3 lightDir;

        attribute vec3 vNormal;
        attribute vec4 vTexCoord;
        attribute vec4 vPosition;

        varying float v_Dot;
        varying vec2 v_texCoord;

        void main()
        {
            gl_Position = u_modelViewProjMatrix * vPosition;
            v_texCoord = vTexCoord.st;
            vec4 transNormal = u_normalMatrix * vec4(vNormal,1);
            v_Dot = max(dot(transNormal.xyz, lightDir), 0.0);
        }

</script>

<script id="fshader" type="x-shader/x-fragment">

        uniform sampler2D sampler2d;

        varying float v_Dot;
        varying vec2 v_texCoord;

        void main()
        {
            vec2 texCoord = vec2(v_texCoord.s, 1.0 - v_texCoord.t);
            vec4 color = texture2D(sampler2d,texCoord);
            color += vec4(0.1,0.1,0.1,1);
            gl_FragColor = vec4(color.xyz * v_Dot, color.a);
        }

</script>

The vertex shader in this example simply sends along the vertex position, vPosition to the fragment shader after transforming it by a composite model-view/projection matrix. We’ll get to that later. Then it passes along the texture coodinate, vTexCoord, and uses the normal in vNormal to compute a lighting factor, v_Dot for the fragment shader. The fragment shader is even simpler. It just gets a pixel from the texture, (after flipping the texture coordinate so the image is right-side up). Then multiplies that by the lighting factor passed in from the vertex shader. This causes the pixels to be brighter when a side of the cube is facing you and darker when it is at an angle, giving it a realistic lighting effect.

Initializing the Engine

Now we have to get WebGL up and running. The utility library we first loaded will help us here:

    function init()
    {
        // Initialize
        var gl = initWebGL(
                // The id of the Canvas Element
                "example1",
                // The ids of the vertex and fragment shaders
                "vshader", "fshader",
                // The vertex attribute names used by the shaders.
                // The order they appear here corresponds to their index
                // used later.
                [ "vNormal", "vTexCoord", "vPosition"],
                // The clear color and depth values
                [ 0, 0, 0, 1 ], 10000);

        // Set some uniform variables for the shaders
        gl.uniform3f(gl.getUniformLocation(gl.program, "lightDir"), 0, 0, 1);
        gl.uniform1i(gl.getUniformLocation(gl.program, "sampler2d"), 0);

        // Enable texturing
        gl.enable(gl.TEXTURE_2D);

        // Create a box. On return 'gl' contains a 'box' property with the 
        // BufferObjects containing the arrays for vertices, normals, texture 
        // coords, and indices.
        gl.box = makeBox(gl);

        // Load an image to use. Returns a CanvasTexture object
        spiritTexture = loadImageTexture(gl, "spirit.jpg");

        // Create some matrices to use later and save their locations in the shaders
        gl.mvMatrix = new CanvasMatrix4();
        gl.u_normalMatrixLoc = gl.getUniformLocation(gl.program, "u_normalMatrix");
        gl.normalMatrix = new CanvasMatrix4();
        gl.u_modelViewProjMatrixLoc =
                gl.getUniformLocation(gl.program, "u_modelViewProjMatrix");
        gl.mvpMatrix = new CanvasMatrix4();

        // Enable all the vertex arrays
        gl.enableVertexAttribArray(0);
        gl.enableVertexAttribArray(1);
        gl.enableVertexAttribArray(2);

        // Setup all the vertex attributes for vertices, normals and texCoords
        gl.bindBuffer(gl.ARRAY_BUFFER, gl.box.vertexObject);
        gl.vertexAttribPointer(2, 3, gl.FLOAT, false, 0, 0);

        gl.bindBuffer(gl.ARRAY_BUFFER, gl.box.normalObject);
        gl.vertexAttribPointer(0, 3, gl.FLOAT, false, 0, 0);

        gl.bindBuffer(gl.ARRAY_BUFFER, gl.box.texCoordObject);
        gl.vertexAttribPointer(1, 2, gl.FLOAT, false, 0, 0);

        // Bind the index array
        gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, gl.box.indexObject);

        return gl;
    }

After this initialization we have the shaders loaded and attached to a GLSL program, which is how you define the interface to your shaders. You pass uniforms to a shader for values that don’t change, and vertex attributes for things that do, like vertices. Most of this is taken care of in the library, but you can pass additional values here, like we do with the lightDir and sampler2d uniforms. Here we also tell WebGL that we want to use the arrays the makeBox() function set up containing the vertices, normals and texture coordinates.

Setting Up the Viewport

Before we can render, we have to tell the canvas how to map the objects we are drawing from modeling coodinates, which is the coordinate space we defined the box in, to viewport coordinates. We do that with a transformation matrix. We will use a perspective projection which will make closer objects look larger than further ones, just like in the real world. Here we will use the matrix library we loaded:

    function reshape(gl)
    {
        var canvas = document.getElementById('example1');
        if (canvas.clientWidth == width && canvas.clientHeight == height)
            return;

        width = canvas.clientWidth;
        height = canvas.clientHeight;

        // Set the viewport and projection matrix for the scene
        gl.viewport(0, 0, width, height);
        gl.perspectiveMatrix = new CanvasMatrix4();
        gl.perspectiveMatrix.lookat(0,0,7, 0, 0, 0, 0, 1, 0);
        gl.perspectiveMatrix.perspective(30, width/height, 1, 10000);
    }

We save the perspectiveMatrix for use later. It transforms from world coordinates to viewport coordinates. We will go from modeling coordinate to world coordinates in the next step.

Drawing the Box

Now we’re all set up and we can finally draw our box. Most of the hard work is done but we still have to tell the box we want it to spin, and to do that we define a model-view matrix, which transforms from modeling coordinates to world coordinates. This tells the box where and at what angle we want it to appear. Then we multiply that by the perspective matrix we saved before to complete the transformation all the way from modeling coordinates to viewport coordinates. We also turn the model-view matrix into a normal matrix so it can be used to compute the proper lighting on the box:

    function drawPicture(gl)
    {
        // Make sure the canvas is sized correctly.
        reshape(gl);

        // Clear the canvas
        gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);

        // Make a model/view matrix.
        gl.mvMatrix.makeIdentity();
        gl.mvMatrix.rotate(currentAngle, 0,1,0);
        gl.mvMatrix.rotate(20, 1,0,0);

        // Construct the normal matrix from the model-view matrix and pass it in
        gl.normalMatrix.load(gl.mvMatrix);
        gl.normalMatrix.invert();
        gl.normalMatrix.transpose();
        gl.uniformMatrix4fv(gl.u_normalMatrixLoc, false,
                gl.normalMatrix.getAsCanvasFloatArray());

        // Construct the model-view * projection matrix and pass it in
        gl.mvpMatrix.load(gl.mvMatrix);
        gl.mvpMatrix.multRight(gl.perspectiveMatrix);
        gl.uniformMatrix4fv(gl.u_modelViewProjMatrixLoc, false,
                gl.mvpMatrix.getAsCanvasFloatArray());

        // Bind the texture to use
        gl.bindTexture(gl.TEXTURE_2D, spiritTexture);

        // Draw the cube
        gl.drawElements(gl.TRIANGLES, gl.box.numIndices, gl.UNSIGNED_BYTE, 0);

        // Finish up.
        gl.flush();

        // Show the framerate
        framerate.snapshot();

        currentAngle += incAngle;
        if (currentAngle > 360)
            currentAngle -= 360;
    }

Once this is all done you simply add a JavaScript timer to keep changing the angle and rendering the box in its new position and you have a spinning box!

Where to Next?

So, as you can see there’s a lot to learn about 3D rendering. There are some nice tutorials at the OpenGL Site. Most of these are not specific to OpenGL ES 2.0, so you’ll have to figure out what features are and are not available. Unfortunately there aren’t a lot of specific ES 2.0 examples yet. But I think these tutorials will give you a good start. There’s also a great book specifically about OpenGL ES 2.0 called the OpenGL ES 2.0 Programming Guide.

There are also a few WebGL examples in the wild already. Check them out here, here and here. WebKit has a few samples as well:

Spinning Box
Earth
Many Planets
Teapot per-vertex
Teapot per-pixel
WebGL+CSS Animation

Exploring Skia

2009-10-18T22:53:18+00:00

Someone recently asked me about the state of shadow support in the Windows Cairo ports of WebKit. As it turns out, the answer is a firm 'it doesn't work.' The reason for this lies in the underlying Cairo graphics library. It doesn't support shadow effects as part of the path rendering. Consequently, programs like Firefox have to generate shadow effects in a separate drawing pass, rather than specifying the 'form' of the shadow and allowing it to be drawn with the main drawing element.

Unfortunately, WebKit's drawing model assumes an underlying graphing system that supports toggling shadows on and off during the rendering of a page. Attempting to shoehorn shadow effects into WebKit (using Cairo) would involve adding extra logic into the drawing system to perform shadow strokes, manually tracking the shadow state somehow and making sure to only perform the extra shadow drawing when needed.

However, another option is to look at using Skia, Google's custom drawing library used on their Chrome browser's port of WebKit. In case you are unfamiliar with the project, Skia is a 2D graphic library for drawing Text, Geometries, and Images. It has built in support for some 3D perspective effects, antialiasing, transparency, and various effects. It has good support for hardware acceleration, and runs on a wide range of hardware platforms.

The bad news is that information about building and running Skia under Windows is pretty non-existant. Clearly it is possible, since all ports of Chrome (including Windows) use Skia, but they project provides no project files (or scons or gyp files), and the gyp files used in the Chromium project don't work outside of the Chromium source tree.

Happily, it's not too hard to figure out which files need to be included in the build, and I found a post by a guy who had gotten things building back in May. Consequently, after a couple of hours of work I was able to get a test application up and running to play with the core library and confirm that it functions properly. I was then able to explore the API a little bit, and confirm that shadows work as expected.

My initial impressions of Skia are very positive. It's nice working with a C++ framework, rather than Cairo's very strict C interface. One puzzling thing about Skia is that the Chromium project has built an extremely useful set of abstractions on top of Skia that seem like they would be well-suited for inclusion. For example, constructing a context for a typical Windows device involves a few steps. But the skia::PlatformCanvasPaint template class takes care of many of these details (as well as cleaning up after itself). Equivalent templates are provided for GTK+ and Mac use. Why leave this in Chromium's private repository? This is useful for everyone!

Over the next week or so I intend to revise the Windows Cairo port to use Skia for its graphical back-end. As a first step, I have updated my requirements.zip file with Skia and it's include files. I have also posted my source tree for Skia, including the Visual Studio solution and my test application (based on WinLauncher).

Pavel Feldman and Dmitry Titov are now WebKit reviewers.

2009-10-13T21:51:22+00:00

Pavel has contributed some great new features for the Web Inspector and spent a lot of time on the Web Inspector to help unfork the Chromium port. Dmitry has worked on timers, workers, test improvements, and various other enhancements.

Please join me in congratulating Pavel and Dmitry on their reviewer status!

What is the size of a QList::Data, RenderObject?

2009-10-12T07:09:07+00:00

We tend to write classes without really caring about what the compile will do to create the binary file. When looking into performance and specially memory usage and you create certain objects thousands of times it becomes interesting of how much memory one is wasting for padding/no good reason.

The Linux kernel hackers wrote a tool called pahole that will analyze the DWARF2 symbols and then spit out friendly messages like the one below.


        struct Data {
                class QBasicAtomicInt     ref;                   /*     0     4 */
                int                        alloc;                /*     4     4 */
                int                        begin;                /*     8     4 */
                int                        end;                  /*    12     4 */
                uint                       sharable:1;           /*    16:31  4 */

                /* XXX 31 bits hole, try to pack */

                void *                     array[1];             /*    20     4 */

                /* size: 24, cachelines: 1, members: 6 */
                /* bit holes: 1, sum bit holes: 31 bits */
                /* last cacheline: 24 bytes */

In this case QList::Data could have used at least three bytes less memory and changing the definition of sharable and array would have removed a whole in the struct. Maybe that is something for Qt5 to keep in mind.

The research question. Can QtWebKit memory usage be reduced by shrinking some of the Qt structs without losing functionality?

QtWebKit on the road towards Qt 4.6

2009-10-11T15:18:07+00:00

I don’t mean “on the road” too literal, but I think we’re on track for a good release, as the following summary of recent changes shows:

Kenneth and Antonio fixed the inconsistent behaviour of setHtml() to sometimes change the history and sometimes not. Simply put, setHtml() should not have any side-effects to the back-forward history.
Joe, Kristian and Janne fixed support for input methods on S60, so for example logging into facebook from Anomaly on a 5800 Xpressmusic works.
Alexis renamed QWebGraphicsItem to QGraphicsWebView, and Raider is now called Twix
J-P Nurmi fixed support for plugins returned by QWebPluginFactory when used with QGraphicsWebView in a canvas: QGraphicsWidget to the rescue.
Girish joined the jungle of WebKit hacking and landed initial support for windowless plugins on X11!
Jocelyn found out why nspluginwrapper wasn’t working properly on Linux and fixed it.
After a long period of review (sorry buddy) we finally landed Jakubs split of the XSLT processor in WebCore to support libxslt as well as QXmlPatterns.
Carol fixed various bugs in GraphicsContextQt for better CSS shadow support.
Holger landed his rewrite of ImageDecoderQt that significantly improves the memory footprint. You can find some background for his work at http://trac.webkit.org/wiki/QtWebKitPerformanceWork

Not all of the above changes are in Qt’s 4.6 branch yet, as we’re trying to reduce the number of changes for the upcoming beta. But rest assured they’ll be in the final release. In the meantime you can always check out from WebKit’s trunk

I for one am now looking forward to meet many of you readers at the upcoming Developer Days in Munich and San Francisco.

The effect of TCmalloc in the QtWebKit port - stage 1: Performance

2009-10-07T13:02:57+00:00

Much time has passed since we started to work on the custom allocation framework with Paul Pedriana. The core of the solution (FastAllocBase class, bug #20422) was landed into the trunk half year ago.

You know what, this clutter thing is cool

2009-10-02T23:49:18+00:00

One of my awesome colleagues from Collabora, Danielle Madeley, has done various improvements to the clutter-gtk project started by the also awesome Alexander Larsson. Reading her blog I was so impressed with this post, that I decided to spend some free time to try out some crazy, experimental stuff using that.

What I did was create a very simple GTK+ widget that derives from GtkClutterEmbed, and works as a somewhat replacement for GtkNotebook, called, proving how bad I am at naming things, GkOverview. Like I said, it’s not really stable or well-done, it doesn’t even free its resources (in fact, it doesn’t even have implementations for finalize and dispose!), it’s really just an experiment.

What GkOverview does is provide a simple API for you to append widgets into it, and it is able to show you one of those widgets, or an overview of all of them. This is quite simple, and yet very powerful. With the help of my significant other, I have got a layout of the widgets in the overview that I really like.

Of course I used WebKitGTK+ to try it out, what else? And since I had effectivelly, at least in my head, created a fairly convincible replacement for GtkNotebook functionality, I decided a second challenge I could take on myself was to make my preferred browser, Epiphany, use that instead of its EphyNotebook widget. Epiphany being quite well-designed, replacing EphyNotebook was quite a breeze, and here’s the result!

Before I go on, let me repeat it: this is all crappy, experimental, curiosity-induced work. It may be that in the future we can use stuff like this to make, say, improving the back/forward mechanism, history navigation, as other browsers do, replacing tabs with a better UI mechanism, and whatnot.

A couple videos, for your pleasure (I was finally able to create a nice video, using Byzanz =)):

Memory profiling on GNU systems

2009-10-02T07:05:09+00:00

This is a small guide on how to observe memory allocations of a process. When carrying out a change it is not only of interest if all test cases still pass, if the benchmarks are faster but it is also important to figure out if there was a change in storage (stack and RAM) requirement.

If you are using the GNU libc it is likely you have a /lib/libmemusage.so installed on your system. This library can be preloaded using LD_PRELOAD and will intercept calls to malloc,free,realloc and various other calls. In short it will trace memory allocations for you. The limitation of that tool is that it will not tell you how much memory the kernel actually mapped, anything about memory fragmentation, etc.

To use libmemusage all you have to do is to prepend MEMUSAGE_OUTPUT=mytrace and LD_PRELOAD=/lib/libmemusage.so to your application. This will instruct the library to write out a trace to the mytrace file.

This trace file can be converted to a graph using the memusagestat utility. It is not installed by most GNU distributions and can be either build from the glibc sources or from the QtWebKit performance measurement utilities. Using memusagestat -o output.png mytrace an image with memory allocations and stack usage like the one at the end of this post will be created. The redline is the heap usage, the green one is the stack usage of the application. The x-scale is the number of allocations.

NOTES: As of today the graph creation with the x-Axis being the time is broken as the generated trace file has some issues, I'm looking into the problem but it will take some more days.

Updates from QtWebKit Land

2009-09-29T08:09:41+00:00

I’ll make this short and sweet and to the point :). Many things happened in the past few weeks in the land of the QtWebKit port:

Kenneth and Antonio landed the first version of QWebGraphicsItem, a simple class that mimics the QWebView API and makes it easy to embed WebKit into the GraphicsView. The API and class name are still subject to change, but we’d love to hear feedback and suggestions, especially from people who have implemented the same thing
Jocelyn submitted QWebInspector, a simple container that gives you control over embedding the web inspector into your application. The API is deliberately minimal to avoid exposing internals.
Tor Arne used his scripting skillz to migrate QtWebKit bugs from our internal company bug tracker into the public WebKit bugzilla. An important milestone towards a more transparent development process on our side.
Yongjun, Janne and Norbert keep on submitting Symbian porting fixes. RVCT builds and runs out of the trunk and WINSCW is very close.
We have updated the copy of WebKit in Qt 4.6 a few times and will continue to do so in the coming weeks towards the 4.6 release. Espen and Janne are also working on getting those WebKit and QtScript Symbian builds into the nightly Qt/S60 snapshots. UPDATE:The latest Qt/S60 nightly includes QtWebKit and QtScript now.

Generally speaking we’re in bugfixing mode. We had to slip in the above few features, but we consider them the exception to the rule. Until 4.6 we’d like to hold off any other changes that affect the API, unless they are actually API bugs or the result of review of new 4.6 API.

Updated WebKit SDK (@r48761)

2009-09-25T18:42:59+00:00

I have updated the WebKitSDK and requirements.zip to correspond to SVN revision r48761.

Major changes in this revision:
* Support for user stylesheet injection.
* Fixes for various layout/rendering issues.
* Various stability and memory improvements.

This bundle also includes Snow Leopard-era CoreFoundation (CFLite), so please let me know if you encounter any strange problems.

The recent WebKit improvements have corrected a few rendering issues I have experienced in the past, so please give this build a try and let me know if you encounter any problems.

Daily binaries of Qt for Symbian/S60 available

2009-09-24T10:00:30+00:00

I promised you daily builds of Qt for Symbian/S60 a few weeks ago, and here they are. Every night at around 02:30 new binaries will be available.

Download the latest binaries from here!

There are two types of files available. You want the latest qt-embedded-s60-opensourceYYYYMMDD-4.6.0-tp1.exe file. The other qt-embedded-s60-opensource-src-4.6.0-tp1.zip is the source package used to create the latest .exe and can mostly be ignored. The .exe contains a Windows Installer as shown below, and here is instructions on how to use it.

There are three Qt .sis files included in the .exe. Most of you (unless you work at Nokia and have an RnD phone) wants to install the qt_for_s60_selfsigned.sis together with the fluidlauncher.sis or whatever application you’re creating yourself.

Works for S60 3.1, 3.2 and 5.0. If you’re using some funky internal RnD SDK, it might work (Hint: use the the “Choose additional folder(s)” option if you’re SDK is not in devices.xml).

The code we’re building from is whatever is HEAD of http://qt.gitorious.org/qt/qt/commits/4.6. In other words if we break the build, no binaries for that day - oh well. At the moment QtScript and QtWekbit are still not there - but soon my friends, soooon.

Update: As of 2009.09.29 the snapshots contains QtScript and QtWekbit as well. Yay we’re so great!.
Update2: Well, we’re not that great it seems. The .dlls gets copied to your epoc32, but they’re not inlucded in the Qt_libs sis files. Fixed now, should be correct in tomorrows snapshots.
Update3: Yepp - was fixed today :D.

Final disclaimer: This is not product quality software. It might make your phone depressed and make kittens cry. Use at your own risk.

Introducing Google Chrome Frame

2009-09-22T18:21:00+00:00

Today, we're releasing an early version of Google Chrome Frame, an open source plug-in that brings HTML5 and other open web technologies to Internet Explorer.

We're building Google Chrome Frame to help web developers deliver faster, richer applications like Google Wave. Recent JavaScript performance improvements and the emergence of HTML5 have enabled web applications to do things that could previously only be done by desktop software. One challenge developers face in using these new technologies is that they are not yet supported by Internet Explorer. Developers can't afford to ignore IE — most people use some version of IE — so they end up spending lots of time implementing work-arounds or limiting the functionality of their apps.

With Google Chrome Frame, developers can now take advantage of the latest open web technologies, even in Internet Explorer. From a faster Javascript engine, to support for current web technologies like HTML5's offline capabilities and <canvas>, to modern CSS/Layout handling, Google Chrome Frame enables these features within IE with no additional coding or testing for different browser versions.

To start using Google Chrome Frame, all developers need to do is to add a single tag:

When Google Chrome Frame detects this tag it switches automatically to using Google Chrome's speedy WebKit-based rendering engine. It's that easy. For users, installing Google Chrome Frame will allow them to seamlessly enjoy modern web apps at blazing speeds, through the familiar interface of the version of IE that they are currently using.

We believe that Google Chrome Frame makes life easier for web developers as well as users. While this is still an early version intended for developers, our team invites you to try out this for your site. You can start by reading our documentation. Please share your feedback in our discussion group and file any bugs you find through the Chromium issue tracker.

Posted by Amit Joshi, Software Engineer, Alex Russell, Software Engineer and Mike Smith, Product Manager

WebKit Page Cache II – The unload Event

2009-09-21T23:29:33+00:00

Previously I touched on what exactly the Page Cache does and outlined some of the improvements we’re working on.

This post is geared towards web developers and is therefore even more technical than the last.

In this article I’d like to talk more about unload event handlers, why they prevent pages from going into the Page Cache, and what can be done to make things better.

Load/Unload Event Handlers

Web developers can make use of the load and unload events to do work at certain points in the lifetime of a web page.

The purpose of the load event is quite straightforward: To perform initial setup of a new page once it has loaded.

The unload event is comparatively mysterious. Whenever the user leaves a page it is “unloaded” and scripts can do some final cleanup.

The mysterious part is that “leaving the page” can mean one of a few things:

The user closes the browser tab or window, resulting in the destruction of the visible page.
The browser navigates from the old page to a new page, resulting in the destruction of the old visible page.

The Page Cache makes this even more interesting by adding a new navigation possibility:

The browser navigates from the old page to a new page, but the old visible page is suspended, hidden, and placed in the Page Cache.

The Status Quo

Unload event handlers are meant to do some final cleanup when the visible page is about to be destroyed. But if the page goes into the Page Cache it becomes suspended, is hidden, and is not immediately torn down. This brings up interesting complications.

If we fire the unload event when going into the Page Cache, then the handler might be destructive and render the page useless when the user returns.

If we fire the unload event every time a page is left, including each time it goes into the Page Cache and when it is eventually destroyed, then the handler might do important work multiple times that it was critical to only do once.

If we don’t fire the unload event when going into the Page Cache, then we face the possibility that the page will be destroyed while it is suspended and hidden, and the unload handler might never be run.

If we don’t fire the unload event when going into the Page Cache but consider firing it whenever the suspended page is eventually destroyed, then we’re considering the possibility of doing something that’s never been done before: Executing scripts that belong to an invisible web page that has had its “pause” button pressed.

There’s all sorts of obstacles in making this work well including technological hurdles, security concerns, and user-experience considerations.

Since there is no clear solution for handling such pages the major browsers vendors have all come to the same conclusion: Don’t cache these pages.

How You Can Help

Web developers have a few things they can do to help their pages be cacheable.

One is to only install the unload event handler if the code is relevant to the current browser. For example, we’ve seen unload handlers similar to the following:

    function unloadHandler()
    {
        if (_scriptSettings.browser.isIE) {
            // Run some unload code for Internet Explorer
            ...
        }
    }

In all browsers other than Internet Explorer this code does nothing, but its mere existence potentially slows down their user experience. This developer should’ve done the browser check *before* installing the unload handler.

Another way developers can improve things is to only install the unload event handler when the page has a need to listen for it, then remove it once that reason has passed.

For example the user might be working on a draft of a document so the developer installs an unload handler to make sure the draft gets saved before the page is left. But they also start a timer to automatically save it every minute or so. If the timer fires, the document draft is saved, and the user doesn’t make any further changes, the unload handler should be removed.

Particularly savvy developers might consider a third option.

A Replacement For Unload

Some time ago Mozilla approached this problem differently by inventing a replacement for load/unload events.

The load and unload events are meant to be fired exactly once, and this is the underlying cause of the problem. The pageshow/pagehide events – which we’ve implemented in WebKit as of revision 47824 – address this.

Despite their name the pageshow/pagehide events don’t have anything to do with whether or not the page is actually visible on the screen. They won’t fire when you minimize the window or switch tabs, for example.

What they do is augment load/unload to work in more situations involving navigation. Consider this example of how load/unload event handlers might be used:

    <html>
    <head>
    <script>

    function pageLoaded()
    {
        alert("load event handler called.");
    }

    function pageUnloaded()
    {
        alert("unload event handler called.");
    }

    window.addEventListener("load", pageLoaded, false);
    window.addEventListener("unload", pageUnloaded, false);

    </script>
    <body>
    <a href="http://www.webkit.org/">Click for WebKit</a>
    </body>
    </html>

Click here to view this example in a new window, in case you can’t guess what it does.

Try clicking the link to leave the page then press the back button. Pretty straightforward.

The pageshow/pagehide fire when load/unload do, but also have one more trick up their sleeve.

Instead of firing only at the single discrete moment when a page is “loaded” the pageshow event is also fired when pages are restored from the Page Cache.

Similarly the pagehide event fires when the unload event fires but also when a page is suspended into the Page Cache.

By including an additional property on the event called “persisted” the events tell the page whether they represent the load/unload events or saving/restoring from the Page Cache.

Here’s the same example using pageshow/pagehide:

    <html>
    <head>
    <script>

    function pageShown(evt)
    {
        if (evt.persisted)
            alert("pageshow event handler called.  The page was just restored from the Page Cache.");
        else
            alert("pageshow event handler called for the initial load.  This is the same as the load event.");
    }

    function pageHidden(evt)
    {
        if (evt.persisted)
            alert("pagehide event handler called.  The page was suspended and placed into the Page Cache.");
        else
            alert("pagehide event handler called for page destruction.  This is the same as the unload event.");
    }

    window.addEventListener("pageshow", pageShown, false);
    window.addEventListener("pagehide", pageHidden, false);

    </script>
    <body>
    <a href="http://www.webkit.org/">Click for WebKit</a>
    </body>
    </html>

Click here to view this example in a new window, but make sure you’re using a recent WebKit nightly.

Remember to try clicking the link to leave the page then press the back button.

Pretty cool, right?

What These New Events Accomplish

The pagehide event is important for two reasons:

It enables web developers to distinguish between a page being suspended and one that is being destroyed.
When used instead of the unload event, it enables browsers to use their page cache.

It’s also straightforward to change existing code to use pagehide instead of unload. Here is an example of testing for the onpageshow attribute to choose pageshow/pagehide when supported, falling back to load/unload when they’re not:

    <html>
    <head>
    <script>

    function myLoadHandler(evt)
    {
        if (evt.persisted) {
            // This is actually a pageshow event and the page is coming out of the Page Cache.
            // Make sure to not perform the "one-time work" that we'd normally do in the onload handler.
            ...

            return;
        }

        // This is either a load event for older browsers,
        // or a pageshow event for the initial load in supported browsers.
        // It's safe to do everything my old load event handler did here.
        ...
    }

    function myUnloadHandler(evt)
    {
        if (evt.persisted) {
            // This is actually a pagehide event and the page is going into the Page Cache.
            // Make sure that we don't do any destructive work, or work that shouldn't be duplicated.
            ...

            return;
        }

        // This is either an unload event for older browsers,
        // or a pagehide event for page tear-down in supported browsers.
        // It's safe to do everything my old unload event handler did here.
        ...
    }

    if ("onpagehide" in window) {
        window.addEventListener("pageshow", myLoadHandler, false);
        window.addEventListener("pagehide", myUnloadHandler, false);
    } else {
        window.addEventListener("load", myLoadHandler, false);
        window.addEventListener("unload", myUnloadHandler, false);
    }

    </script>
    <body>
    Your content goes here!
    </body>
    </html>

Piece of cake!

How You Can Help: Revisited

To reiterate, we’ve now identified three great ways web developers can help the Page Cache work better:

Only install the event handler if the code is relevant to the current browser.
Only install the event handler once your page actually needs it.
If supported by the browser, use pagehide instead.

Web developers that willfully ignore any or all these options are primarily accomplishing one thing:
Forcing their users into “slow navigation mode.”

I say this both as a browser engineer and a browser user: That stinks!

The Plot Thickens

But now that we’ve covered what savvy and polite web developers can do to help in the future, we need to further scrutinize the current state of the web.

Browsers treat the unload handler as sacred because it is designed to do “important work.” Unfortunately many popular sites have unload event handlers that decidedly do not “do important work.” I commonly see handlers that:

Always update some cookie for tracking, even though it’s already been updated.
Always send an XHR update of draft data to a server, even though it’s already been sent.
Do nothing that could possible persist to any future browsing session.
That are empty. They literally do nothing.

Since these misbehaved pages are very common and will render improvements to WebKit’s Page Cache ineffective a few of us started to ask the question:

What *would* actually happen if we simply started admitting these pages to the Page Cache without running the unload event handler first?

What would break?

Can we detect any patterns to determine whether an unload event handler is “important” or not?

Our Experiment

You never know for sure until you try.

Starting in revision 48388 we’ve allowed pages with unload handlers into the Page Cache. If a user closes the window while the page is visible, the unload event will fire as usual. But the unload event will not be fired as normal when the user navigates away from the page. If the user closes the window while the page is suspended and in the Page Cache, the unload event handler will never be run.

What this means for users is that their navigation experience could be noticeably smoother and quicker in the common case. What this means for developers is that we’re consciously deciding not to run some of their code and their web application might break.

For users and developers alike – Please leave your feedback, observations, or suggestions in the bug tracking this experiment.

And remember this is just an experiment. No one is planning to ship this drastic change in behavior in a production product. But the Page Cache is such an important part of browser performance that we’re willing to push the envelope a little to improve it a lot.

We want to learn what breaks. We want to know if we can heuristically determine if an unload handler is truly critical or not. We want to know if we can detect certain patterns in some types of unload handlers and treat them differently. And, perhaps most importantly, we want to evangelize.

At least one popular Javascript library has already adopted some of the advice we’ve given to help improve the landscape on the web. If just a few more developers for popular sites or libraries take notice of this experiment and change their code then the web will be a much friendlier place for all of us.

WebKit Page Cache I – The Basics

2009-09-16T23:47:13+00:00

This is the first of two posts that will center around a modern browser engine feature that doesn’t usually get a lot of press: The Page Cache.

Today I’ll talk a bit about what this feature is, why it often doesn’t work, and what plans we have to improve it.

Page Cache Overview

Some of you might be more familiar with what other browsers call their Page Cache. Firefox calls theirs the “Back-Forward Cache” or “bfcache.” Opera refers to theirs as “Fast History Navigation.” We’ve recently started to refer to WebKit’s implementation as the “Page Cache” to reduce confusion with our “Back/Forward List.”

Note that the Page Cache is an end user feature that makes navigating the web much smoother. It is not a “cache” in the “HTTP sense“. It is not a “cache” in the “disk cache” sense where raw resources are stored on the local disk. And it’s not a “cache” in the traditional “memory cache” sense where WebKit keeps decoded resources around in memory to be shared between multiple web pages.

So… what *exactly* is it?

Quite simply, the Page Cache makes it so when you leave a page we “pause” it and when you come back we press “play.”

When a user clicks a link to navigate to a new page the previous page is often thrown out completely. The DOM is destroyed, Javascript objects are garbage collected, plug-ins are torn down, decoded image data is thrown out, and all sorts of other cleanup occurs.

When this happens and the user later clicks the back button it can be painful for them. WebKit may have to re-download the resources over the network, re-parse the main HTML file, re-run the scripts that dynamically setup the page, re-decode image data, re-layout the page, re-scroll to the right position, and re-paint the screen. All of this work requires time, CPU usage, and battery power.

Ideally the previous page can instead be placed in the Page Cache. The entire live page is kept in memory even though it is not on screen. This means that all the different bits and pieces that represent what you see on the screen and how you interact with it are suspended instead of destroyed. They can then be revived later in case you click the back button.

Why is This Important?

When the Page Cache works it makes clicking the back button almost instantaneous.

You can do a search, click a search result, then go back and immediately be looking at the exact same results page. You might be browsing an aggregator site like Reddit or Digg and want to rapidly view a lot of different links in the same tab. You might be navigating an image gallery and decide to compare two images by alternately clicking “back” and “forward” rapidly. Or you might have simply clicked on the wrong link and want to go back to correct your mistake.

Anytime you might click the back button or the forward button you unknowingly hope the Page Cache is on your side. When the Page Cache is used, users are happy even though they’re not aware of the magic behind the scenes.

Conversely, when the Page Cache is bypassed, users often get frustrated with both the browser and the Web in general.

Why Wouldn’t it Work?

So if the Page Cache is so amazing, why doesn’t WebKit always use it when you navigate to a new page?

There’s a few main answers to that question.

Some Pages aren’t Interesting

First off, sometimes it doesn’t make sense to cache a page because it’s not interesting to return to in the exact same state. For example, the page might not even be finished loading yet. Or the page might’ve had an error loading. Or maybe the page was a redirection page that exists solely to automatically move the user to some new URL.

These are cases where we’re happy with the current Page Cache behavior in WebKit.

Some Pages are Complicated

Secondly, a page might not be considered for the Page Cache because it’s difficult to figure out how to “pause” it. This happens with more complex pages that do interesting things.

For example, plug-ins contain native code that can do just about anything it wants so WebKit can’t “hit the pause button” on them. Another example is pages with multiple frames which WebKit has historically not cached.

Distressingly, navigating around these more advanced pages would benefit the most from the Page Cache.

Some Pages are Secure

Server administrators for HTTPS sites often have particular security concerns and are very sensitive with regards to how browsers behave. For example, Financial institutions are often very thorough in verifying each particular browser’s behavior before allowing it to be used by their customers.

One area often focused on is back/forward behavior. Such institutions are – understandably – very picky about the types of data left behind in the browser as a user navigates. As a result, in an effort to err on the side of extreme caution, WebKit has disallowed all HTTPS sites from its Page Cache since the very beginning.

A more fine grained approach might go a long way towards improving the user experience.

Planned Improvements

Clearly there’s some important cases we don’t handle and therefore plenty of room for improvement.

WebKit’s Page Cache was originally written in 2002 before the very first Safari beta release. Its capabilities reflected both the architecture of WebKit at the time and the landscape of the Web in 2002.

The Web of 2009 is a much different place and we need to bring the Page Cache up to par. Fortunately this work is well underway.

For example, as of revision 48036 a major limitation was resolved and pages with frames are now placed in the Page Cache. Browsing with the latest WebKit nightly always seems to “feel faster” in ways you can’t quite put your finger on, and recently some of you might have been experiencing this enhancement.

But there’s plenty more work to do.

Plug-ins are the next huge one on our hit list. As I mentioned earlier, plug-ins can run whatever native code they like so we can’t reliably hit the “pause” button on them.

Earlier versions of WebKit handled single-frame pages with some types of plug-ins. WebKit would tear down the plug-in when leaving the page and restoring it when the user returned. But as work continued on WebCore to make it faster and easier to port, this ability was lost.

Bug #13634 tracks getting this working again for all plug-ins on all pages.

Then there are HTTPS pages. We completely ban them now, but a more selective approach should be able to benefit users as well as keep security-minded institutions happy.

Bug #26777 tracks allowing HTTPS pages to be cached unless their response headers include “cache-control: no-store” or “cache-control: no-cache” which has become the canonical way for a selective organization to secure your content.

If you have any other ideas for what else might be improved, please feel free to comment in the appropriate bug or file a new bug of your own!

Unload Handlers

One thing I haven’t mentioned is pages with unload event handlers.

The unload event was designed to let a page do some cleanup work when the user closes the page.

The browser can’t fire the unload event before it puts the page in the Page Cache, because the page then assumes it is in a terminal state and might destroy critical parts of itself. This completely defeats the purpose of the Page Cache.

But if the browser puts the page in the Page Cache without running the unload handler, then the page might be destroyed by the browser while it is “paused” and hidden, and that cleanup work – which might be very important – will never happen.

Since the unload event’s purpose is to allow “important work when a page is closed,” all major browsers refuse to put such pages in their Page Cache, causing a direct negative impact on the user experience.

In a future post I’ll be talking more about unload event handlers and there will actually be homework for many of you web developers out there! Stay tuned…

Towards a Reopened CFNetwork

2009-09-09T21:46:05+00:00

I think one of the coolest things about Apple, Inc. in their modern incarnation is how great a member of the Open Source community they have become. The fact that the true core of Mac OS, the Darwin BSD implementation, is open and available for all interested parties to review, modify, and learn from is unprecedented in any commercial company I am aware of (at least, none that started off life as a closed-source entity.)

In addition to the core OS components from the Darwin layer, they have contributed improvements to the GNU compiler collection, their amazing WebKit rendering engine, spearheaded the OpenCL initiative, shepherded LLVM into an absolutely amazing compiler system, provided a fantastic local host resolution and routing system (Bonjour), and have contributed the equivalent of millions of dollars in development value to the world at large.

Amazing!

So of course I am writing this post to ask for EVEN MORE.

While working on a native Windows port of WebKit (one unencumbered by proprietary Apple libraries that prohibit redistribution), I started working with CoreFoundation. Along with the many other products I listed above, they opened a large subset of the full CoreFoundation product as CF-Lite, large enough in fact to support running WebKit. They even provided useful examples and arguments for basing a porting strategy around CF-Lite. While they make dumps of the CF-Lite source tree available with each Mac OS release, they did not generally release Linux or Windows sources (which had to be recreated externally). They were also uninterested in opening it up as a WebKit-style open source project, so I started hosting them as the opencflite project on SourceForge. We now fully support Mac OS X (a no-brainer), Windows, and Linux.

CoreFoundation is really neat because of its various data types and operating system abstractions, but it also has a nice modular system for modelling various operating system elements (such as sockets, files, timers) as part of a common runloop, allowing easy asynchronous operations. What is even neater is when you can make use of CoreFoundation's sister framework, CFNetwork, which extends this idea to various network features, such as Host lookup, DNS, and Bonjour.

Up through Mac OS X 10.4 (Tiger), CFNetwork was Open Source software. Alas, those salad days were not to last. With the release of Mac OS X 10.5 (Leopard), CFNetwork closed up and has not been seen in the wild since.

Initially I thought this was a mistake, but after corresponding with Apple's Open Source Product Manager I was informed that it was indeed closed on purpose. After a couple of years of e-mailing various parties associated with the CoreFoundation/CFNetwork product line, I eventually filed rdar://7195752 to request the source to be reopened.

I'm not sure why CFNetwork was closed. But even if it contains Secret Alien Technology, I believe that portions of it could be made available in an Open Source form. In my bug report, I gave an impassioned plea that basically boiled down to the following bullet points:

Increased uptake of CoreFoundation as a general purpose, cross-platform library would facilitate porting of applications to the Mac OS.
Security engineers would be able to audit and validate the source code, increasing overall platform security.
Presence of the source and examples on more development platforms would increase developer mind share, and help extend the visibility and utility of Apple development tools.
More eyes looking at the code would benefit the source base as a whole.

As I conclude in my bug report, I sincerely hope that Apple could be convinced to open source at least portions of CFNetwork so that its use could be extended outside of Apple. This would greatly aid in my efforts to keep the Windows Cairo port of WebKit in sync with the full Apple version, as well as allowing work on the PureDarwin project to continue.

Updated WebKit SDK (@r48212)

2009-09-09T16:21:20+00:00

A new WebKit SDK, now new and improved with no multiple-MSVCRT linkage!

This build corresponds to the new requirements.zip I uploaded last night. This should be suitable for running on an end-user system (assuming it has been updated to the current patchlevel for MSVCRT). If the user is running 'Windows Update' this should be a safe assumption.

Please try it out and let me know if you have any problems.

WebKitGTK+ 1.1.14 new features

2009-09-09T09:53:02+00:00

Gustavo has written a nice sumary of all the new APIs in 1.1.14 (yes, all that stuff was only for 1.1.14!), so go and check it out if you are interested.

Revised Requirements

2009-09-09T02:26:39+00:00

A couple of people who have been working with the WebKitSDK reported problems when running WinLauncher (or other applications based on WebKit.) This was tracked down to the WebKit.dll manifest, which contained dual entries for the Visual Studio runtime:


assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"

versus


assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"

I initially planned on rebuilding everything using static linkage to the CRT, but quickly found that this would require changing far too many project files (including every existing WebKit project). This quickly got out of hand, so I simply rebuilt against the current set of libraries and called it a day.

You can grab the new requirements here. If you update to current SVN you will have proper link instructions to build a correct set of executables and DLLs.

WebKitGTK+ 1.1.14 is here!

2009-09-08T14:38:10+00:00

1.1.14 is definitely worth blogging about. While I was updating the gtk-doc stuff to update the documentation that is available in our website I was thinking that this is probably the release with the largest amount of API addition I have seen in my time as a contributor to the project! Before I start talking about the new APIs, though, let me talk of something that went under the hood: Xan has patched WebKitGTK+ to override libsoup’s connection limits, so that our limits match those of other modern browsers - we now allow up to 60 connections total, and 6 per host. People have been reporting load performance improvements for some sites!

We have an initial set of APIs to deal with the data that was loaded to render the page, represented by the new DataSource object. This allows you to peek at the source of the HTML that was rendered, for instance. In the near future we will have ways of getting the data and other information for each resource that is downloaded to compose the page. Jan Alonzo has spent quite some time studying, implementing and perfecting this API, with some help from me and Xan.

One initial piece of the larger API to control resource loading is already there, as well. The WebView will use the new resource-request-starting signal to let you know that a request is about to be sent, and allow you to modify headers, or even the URI that is going to be fetched. For some, the greatest news here is that this allows a basic implementation of AD blocking, which is now supported in Epiphany with the WebKit backend, as of version 2.27.92, released today! This is something I have been looking at in my Collabora time for some time now, and working along with Xan and Jan, we finally seem to have figure out the API interactions correctly. There’s more to come regarding resource loading tracking, in the near future.

That would already be a lot, from my point of view, but there’s a whole lot more. A new contributor, Martin Robinson, has arrived proposing new API pieces for an important HTML5 tool: web databases, which brings with it the concept of SecurityOrigin. Jan has exposed API to put the WebView in “view source” mode, Xan has given us undo/redo support for editable content, and Zan Dobersek has done some overall improvement of our HTML5 media player.

That’s a lot of change for a release, which also goes to show we still have quite a gap to fill, but we are being able to move forward and fill them quite quickly. If you want to help out, pick something in your area of interest, and send us patches!

The show so far

2009-09-08T12:53:02+00:00

Yesterday we released WebKitGTK+ 1.1.14, Epiphany 2.27.92 and Epiphany-Extensions 2.27.92. I haven't blogged about releases in a while (sorry!), and as the good people at Ars Technica mention development is moving at a "swift rate" (btw Ryan, you can remove the ugly hack to get the contents of the page ...

Eric Carlson is now a WebKit Reviewer

2009-09-01T10:34:30+00:00

Eric Carlson has been a long-time contributer to WebKit, first through the QuickTime Plugin, and now directly as part of WebKit’s HTML5 media support. Eric knows a ridiculous amount about video and audio and we’re very glad to have him now as an official reviewer! Please join me in welcoming Eric as a reviewer.

Updated Build

2009-08-26T08:43:19+00:00

I haven't posted much recently, but rest assured I am continuing to work on WebKit in a variety of areas. I found (and corrected) a few issues in the libcurl backend, but you were only likely to run into them if you were working a lot with local files (e.g., stuff in your filesystem) which happens to be something I'm doing a lot of right now. The build now contains corrections for these items.

At the moment, I am working on making it easier for people to use WebKit in projects without having to invest massive amounts of time to figure out how to build the framework themselves.

To that end, I am ditching the separate Debug and Release bundles I had been producing, and am paring things down to a single WebKitSDK zip file, which contains the Debug and Release binaries in a single package. I first had to modify WebKit to emit dll's with "_debug" names so that everything could coexist peacefully in a single bin folder. Now that this is all bundled together, I have removed the original Debug and Release-only zip files from my iDisk.

Now that I've got that finished up, I'm going to focus on shrinking the runtime dependencies by trying to link more of the components statically. I am also trying to get the libcurl support into a background worker to improve throughput.

Of course, if any of you have more pressing concerns, let me know or file a bug!

Presentation with S5

2009-08-25T15:00:01+00:00

Influenced by Holger and Simon, I decided to use S5 for my presentation at the Desktop Summit in Gran Canaria few weeks ago. It’s purely based on web technologies, it works in modern web browsers. More information is available at the official website, including demos, even with different styles and effects. Thanks to the use of web technologies, you can even create the slides online.

For the fun of it, instead of just using a web browser (so boring!), I wrote a simple QtWebKit-based tool to run the slide shows, dubbed s5runner. The code is checked in already to the Graphics Dojo repository. Beside just launching the slide shows in a QWebView, the 200-lines C++ code adds a few more goodies (although arguably, all these extra stuff can be implemented in pure HTML/CSS/JavaScript instead). Run the program and open the included slides.html (in the example sub-directory), or just enjoy the following 2-minute screencast:

A countdown timer (currently hard-coded to 30 minutes) is installed at the bottom right corner. The screen can be blanked temporarily to black or white, useful when you want to steal the focus of the audience from the slides. Going full-screen (and back again) is also easy, this is important if you’d like to show some live demos during the talk. The slides look ugly due to the aging or faulty projector? Use the night-mode, something you have seen in the previous OpenStreetMap example.

When doing a talk about programming, it is often unavoidable to show code snippet. Thanks to Chili, the jQuery code highlighter plugin (there are other alternatives to pick:
prettify, syntaxhighlighter, and many others), you will get the highlighting feature with zero effort. It’s quite useful as the code fragment (which you likely show only for a few seconds) becomes more understandable. My favorite is however the live-editing feature, just press F3 to start editing the slide while you are showing it at the same time.

If you like this presentation tool, feel free to extend it. For example, you can have more presentation effects, like pulsating or shaking, by using script.aculo.us-based Presentacular. This example tool only supports basic editing, but I have shown a WYSIWYG HTML Editor before, so you can augment its editing features to support e.g. inserting images from the disk, changing character and paragraph styles, and so on. And of course, support for PDF export (with one slide per page) will be just very nice. A PowerPoint-killer, anyone?

WebKit on non mainstream platforms

2009-08-17T19:01:48+00:00

We have seen some interest in MIPS on the mailinglist and little in the bugtracker but no contribution from these folks. So the other week I decided to attempt to run some of our regression tests on a MIPS platform. The only problem is that I don't have any MIPS hardware... can you change that?

I had this idea of implementing enough of MacroAssembler to run/compile yarr with the RegexJIT.cpp. In the absence of MIPS hardware I used qemu-mipsel useremulation, enabled yarr/RegexInterpreter.cpp and ran into an infinite loop. I have fixed the bug and landed the patch upstream and now I'm able to complete run-javascriptcore-tests using yarr. The next step will be to work on the MacroAssembler and learn about MIPS assembly.... maybe I progress a bit more next weekend.

WebKit (r47083) Build Pushed to iDisk

2009-08-12T00:48:07+00:00

I've pushed an updated build (with HTTPS support) to my iDisk. A Debug version is also available at the same place.

If you intend to build WebKit yourself, you should use the current requirements.zip file for your building pleasure. In addition to the SSL-enabled cURL, it contains a slightly updated CFLite that brings it up to Mac OS 10.5.8 level.

These builds include the cURL cacert.pem file in WebKit.resources/certificates/cacert.pem. If you have another certificate bundle you would like to use, just copy it to this location (and name).

WinCairo WebKit Supports SSL

2009-08-12T00:31:46+00:00

The guys at Appcelerator figured out how to enable SSL support in their local build of the WinCairo port, and passed along the three-line change required to do so.

Of course, there was a little bit more to it than that, mainly involving figuring out how to (a) build OpenSSL on Windows, (2) how to build libcurl with SSL enabled, and (iii) how to link WebKit with all of this stuff.

I managed to swell their three-line modification into around twenty lines, but in my defense I wanted to make it possible to have WebKit look for the SSL certificate in the WebKit bundle directory (falling back to the CURL_CA_BUNDLE_PATH environment variable only if necessary).

So now you can locate a certificate bundle in "WebKit.resources/certificates/cacert.pem", and WebKit will find it and use it. If not, you have to set the CURL_CA_BUNDLE_PATH environment variable to the desired location.

The upshot of all this is that I am posting this blog note via WinLauncher (after logging into Blogger.com using HTTPS), and I closed out ~~Bug 28171~~ via WinLauncher (over HTTPS) as well!

Short QtWebKit Development Update

2009-08-04T08:17:37+00:00

In the past few weeks the development of the Qt port of WebKit has seen a lot of progress. I would like to highlight a few items:

Kent, Olivier, Jedrzej, Benjamin, Tor Arne and Ariya have been hacking away on the new backend for QtScript to use JavaScriptCore. We’re down to only a handful of issues (~10, so both hands are needed).
Since Akademy the entire team has been cleaning up the layout tests and the DumpRenderTree tool, to get the test infrastructure back in shape.
Gabor, Rapcsanyi and Zoltan from the University of Szeged have been working hard on bringing the build bot for the Qt WebKit port back online. Since last weekend it’s finally back online in green (yay) at the bot farm at http://build.webkit.org/waterfall!
In a multi-platform marathon Tor Arne has been working on cleaning up the WebCore plugins code to eliminate duplicated code between the ports and to unify the behaviour in things like startup sequence and error handling.
While we’re at plugins, Jakob from the Arora team has started developing a settings API for plugins, to enable/disable them or to specify preferences.
Laszlo and Norbert continue to submit patch after patch for the S60 port, it’s progressing nicely!

In between we had a little team barbeque here in Oslo, celebrating our recent hackeries with food and games:

Maps with a Magnifying Glass

2009-07-29T06:53:19+00:00

Google Maps, or any similar application, becomes very important in our digital life. Not surprisingly, it also becomes easier to integrate some map functionalities into our application. This is something that attracts the developer side of each and every one of us. The brand-new, work-in-progress Google Maps API v3, via the use of QtWebKit module, is the instant solution for embedding maps in your own beloved Qt-based application.

Since doing so would be almost trivial (you can even do it within Designer or Creator), I decided to raise the bar a bit. What if, when your press the mouse button and hold it for a while, a magnifying glass (remember Sherlock Holmes?) shows up and you can move it around? Thanks to Qt, surprisingly (again) implementing such a demo is easy, the result is less than 300 lines of code, and thus I am glad to share you how it looks like, in a static screenshot and a moving picture (watch in YouTube):

The code is checked in already to the Graphics Dojo repository, it is securely stashed under the mapzoom subdirectory. If you do not bother to digest the code, here is the trick. I keep a larger version of the map in a separate QWebPage. When the user press-and-hold the mouse button for a while, this hidden page is used to render the maps under the magnifying glass, clipped to the shape of a circle. Simple, isn’t it? Of course, you can still move the maps by dragging the mouse, just like in the normal use of Google Maps.

Now I am sure some of you are ready to throw the questions. What about Qt/S60 version? What about OpenStreetMap? Relax and be patient a bit. The combination of both will surely make a cameo, some time in the near future, in the form of another example (a successor to this one). Meanwhile, enjoy your maps, Sherlock!

WebKit's week - #9

2009-07-21T12:06:00+00:00

Week from May 11 to May 24 (before r44117). To test those changes, you'll need a WebKit nightly.

New input types (43267)

4 new input fields are now supported : url, mail, number et tel (see the HTML5 spec). No additional functionality (like completion with the address book, the bookmarks, etc), just a basic support. But we can guess those functionalities will be available later.

ARIA role : grid(43669)

Even if Safari 4 has a basic support of WAI-ARIA, the work is not over. New roles are still coming in.

Orientation and ratio available in CSS (43739)

Media queries in CSS give a better control through knowledge of the properties of the device. WebKit already supports some of those queries. This change adds support for orientation (portrait or landscape) and ration (exact, minimal or maximal) of the view.

displayName support in the debugger (43774)

Anonymous functions are often used in JavaScript. They are really handy for development but not so much when you have to find where a problem lies. Therefore, Francisco Tolmasky of 280North got the idea of the function.displayName property. You can now choose what name the debugger will use. Before that, he has also done a similar change for the profiler. I can only recommend the lengthy article he wrote about it.

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.

The WebKit mailinglists

2009-07-18T14:54:56+00:00

In the beginning there was webkit-dev but we were overwhelmed by the feedback we got. Last week Maciej announced how to use the new lists.

webkit-dev should be used for the development of WebCore/JavaScriptCore itself.

webkit-help should be used for questions on how to use WebKit API in applications, porting to new platforms, building it...

webkit-jobs is there to not force one to send job posts to every single commiter but to only one place.

A Thank You!

2009-07-17T00:32:35+00:00

A few weeks ago I posted a request for a valid, legal license for Microsoft Windows so that I could do more WebKit work on the weekends or when I only had my MacBook Pro at hand.

I'm shocked and delighted to report that a kind donor (who wishes to remain anonymous) has provided me with a brand new Windows Vista boxed set. This is an expensive and very helpful donation, and I greatly apreciate it.

So many thanks to my anonymous benefactor, and I'm off to buy a larger hard drive so I can set up a respectable partition for it.

3D Transforms

2009-07-16T19:02:29+00:00

WebKit on Mac OS X now has support for CSS 3D transforms, which allow you to position elements on the page in three-dimensional space using CSS. This is a natural extension of 2D transforms, which we described in an earlier blog post. 3D transforms have been supported on iPhone since 2.0, and now we’re please to announce that we have currently added support for Leopard and later.

If you want to jump right in and see a demo, make sure you’re running recent WebKit nightly build on Leopard or later, and load this example:

Poster Circle

Here’s a screenshot for those not running a recent-enough WebKit (if you are, hover over it for a treat!):

Like many of the examples you’ll see here, this one combines CSS transforms with CSS transitions and animations to great effect.

3D transforms are applied via the same -webkit-transform property as 2D transforms. For example, here’s how to rotate an element about the Y (vertical) axis:

-webkit-transform: rotateY(45deg);

There are several new transform functions available for use in the -webkit-transform property:

translate3d(x, y, z), translateZ(z): Move the element in x, y and z, and just move the element in z. Positive z is towards the viewer. Unlike x and y, the z value cannot be a percentage.
scale3d(sx, sy, sz), scaleZ(sz): Scale the element in x, y and z. The z scale affects the scaling along the z axis in transformed children.
rotateX(angle), rotateY(angle), rotate3d(x, y, z, angle),: The first two forms simply rotate the element about the horizontal and vertical axes. Angle units can be degrees (deg) radians (rad) or gradians (grad). The last form allows you to rotate the element around an arbitrary vector in 3D space; x, y and z should specify the unit vector you wish to rotate around (we’ll normalize it for you).
perspective(p): This function allows you to put some perspective into the transformation matrix. For an explanation of p, see below. Normally perspective is applied via the -webkit-perspective property, but this function allows you to get a perspective effect for a single element, with something like:

-webkit-transform: perspective(500px) rotateY(20deg);

matrix3d(…)

This function allows you to specify the raw 4×4 homogeneous transformation matrix of 16 values in column-major order. Have fun with that!

We’ve also extended one other CSS transform property, and implemented the four other 3D-related properties described in the spec:

-webkit-transform-origin now accepts three values, allowing you to specify a z offset for the transform origin.

-webkit-perspective is used to give an illusion of depth; it determines how things change size based on their z-offset from the z=0 plane. You can think of it as though you’re looking at the page from a distance p away. Objects on the z=0 plane appear in their normal size. Something at a z offset of p/2 (halfway between the viewer and the z=0 plane) will look twice as big, and something at a z offset of -p will look half as big. Thus, large values give a little foreshortening effect, and small values lots of foreshortening. Values between 500px and 1000px give a reasonable-looking result for most content.

The default origin for the perspective effect is the center of the element’s border box, but you can control this with -webkit-perspective-origin.

Here’s an example that shows how perspective works:

Perspective

The interesting thing about -webkit-perspective is that it does not affect the element directly. Instead, it affects the appearance of the 3D transforms on the transformed descendants of that element; you can think of it as adding a transform that gets multiplied into the descendant transforms. This allows those descendants to all share the same perspective as they move around.

We’ve described how you can assign 3D transforms to elements and make them look three-dimensional with some perspective. However, so far, all the effects are really just painting effects. Those transformed children are still rendering into the plane of their parent; in other words, they are flattened.

When you start to build hierarchies of objects with 3D transforms, flattening is not what you want. You want parents and children to live in a shared three-dimensional space, and to all share the same perspective which propagates up from some container. This is where -webkit-transform-style comes in.

-webkit-transform-style has two values:

flat: This is the default value, and gives the behavior described above; transformed children are flattened into the plane of their parent (think of the 3D transform as simply a painting effect).
preserves-3d: This value states that the element to which it is assigned does not flatten its children into it; instead, those children live in a shared 3D space with the element.

Here’s an example that shows transform-style in action:

Transform Style

A common pattern, therefore, is to have content that looks like this:

<div class="container" style="-webkit-perspective: 600px">
  <div class="box" style="-webkit-transform-style: preserve-3d; -webkit-transform: rotateY(10deg)">
    <div class="leaf" style="-webkit-transform: rotateX(10deg)"></div>
  </div>
</div>

Here both ‘leaf’ and ‘box’ share the same 3D space, so both appear with the perspective specified on the container. ‘box’ can also be rotated with a transition or animation, and ‘leaf’ will move around as ‘box’ moves, in perspective.

One thing you may have noticed in these demos is that it’s quite common to have a 3D transform that flips an element around so that you can see its reverse side. In some cases you don’t want the element to appear at all in this situation (say, for example, you want to position two elements back-to-back, so you need to hide the one that’s facing away from the viewer). This is the reason for the last 3d-related property, -webkit-backface-visibility. Its two values—visible (the default), and hidden—specify whether the element is visible or not when that element is transformed such that its back face is towards the viewer.

Here’s a final example that shows backface-visibility in action, along with more 3D goodness, animations and transitions:

Morphing Power Cubes

For more information, see the CSS working drafts on 2D transforms, 3D transforms, transitions and animations. There is also documentation in the Safari Reference Library.

We hope you have a blast with these new features, and share your creations with us. If you find bugs, please report them at bugs.webkit.org.

WebKitGTK+ progress, and a new browser!

2009-07-16T11:43:17+00:00

Long time, no blog. I have apparently been slacking for a very high number of versions, now, so I better start doing something about it!

My last blog was about 1.1.7, and we are now at 1.1.11, so let me try to get a quick summary of important changes since 1.1.17:

Lots of fixes have been made on the scrolling code, which now behaves more like you would expect from a GTK+ widget, and notifications to web applications are also working now
Thanks to the awesome zecke, you can embed arbitrary GTK+ widgets using the <object> and <embed> tags, using the create-plugin-widget signal
WebKitNetworkRequest received a lot of the love it was asking for, and is now very useful for tracking the HTTP conversation
Xan has done awesome work on a11y, and we may have enough done before 2.28 to make WebKitGTK+ be accepted, but that remains to be seen; if you care about that, now is a good time to go to https://bugs.webkit.org/show_bug.cgi?id=25531 and help out!
XSS auditor, a new feature built to improve WebKit’s security is now enabled
Copying and pasting has seen many improvements
WebKitGTK+ no longer has hackish content sniffing, since we now have that implemented into libsoup!

In other news, WebKitGTK+ seems to have gained another application for its ecosystem: Uzbl, which promises to be a good browser for people who like to work with the UNIX way. It doesn’t really appeal to my GNOMEr ‘I like things that just work’ heart, but it looks like a tool that may appeal to people who prefer building their work environments from various different pieces, so that it works exactly like they want to. I am very happy to see WebKitGTK+ is making it possible for people to write such tools!

WebKit Cairo Windows Port Landed!

2009-07-13T18:21:44+00:00

It's been a long, hard road, but today marks the commit of the last missing element of the Windows Cairo port.

Literally every bit of code I use on my system to build WebKit on Windows using the non-Apple support libraries is now part of the official WebKit archive. This means that you can now embed a WebView in your Windows application that harnesses the full power and features of the best rendering engine out there.

To celebrate, I am posting here an image of Satine.org's CSS animation demo"SnowStack". It runs fairly well on my local Debug build.

Out of sheer meanness, I am also attaching the same website viewed with IE 8...

I Need Port Name Ideas!

2009-07-10T01:07:14+00:00

One of the few remaining tasks holding up complete integration of the Redistributable Windows WebKit port is an official name. I tried using the term "Redistributable WebKit", but this met with somewhat negative feedback.

So, what do all of YOU think would be a good name?

Maybe I could commandeer the abandoned SquirrelFish name? ;-)

Clearing caches on system signal

2009-07-06T11:28:21+00:00

Currently, I'm experimenting with WebKit to release all the memory what we can on given conditions. This can be useful in low memory situations or when the system goes asleep (less RAM usage needs less power).

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-25T18:33:33+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.

Ever wanted to compare different JIT engines? Now that is possible!

2009-06-25T14:14:12+00:00

It is well known that runtime profiling is handy when we want to measure the runtime cost of different functions, identify the performance bottlenecks of the code, or measure the progress of the project over a period. However, most profiling mechanisms are tied to a specific project, which makes the comparison of different solutions impossible. I have developed a simple library, which can easily be added to any existing JIT engine. The attached tgz contains patches for wide-spread JIT engines (namely WebKit-JavaScriptCore and Tamarin-NanoJIT).

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 destined to get its own content sniffer

2009-06-21T20:50:34+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: Facilitating alternative/experimental implementations of existing features vs. discouraging unnecessary duplication of efforts

2009-06-21T18:45:14+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…]