I'm now back home after BeGeistert. As you may have noticed if you read the development mailing list, there is a general agreement from the development team for a beta 1 release "real soon now", and after that, it will be time for R1. I will be coordinator for these, which means I will spend a bit less time on WebKit to take care of some other tasks. But I'm not giving up on WebKit, which still needs a lot of changes to reach release-quality.
I was a bit less active this week as I had to recover from the lack of sleep at BeGeistert. But it's all fine now and I should soon be back at full speed.
This week is a bit special, as it closes the first year of my contract with Haiku. I wish to thank everyone for their support through donations, bug reports, comments on these articles, and general support for my work. I hope this will continue into next year.
This was again a rather busy week, but there was not much work on WebKit itself. I'll keep the breakdown I used last week (haiku/haikuports/webkit) as it seems to work well.
This week most of my work went into improving our HTML5 support in WebKit. A lot of small issues and relatively simple features had piled up on my TODO list, and there weren't too much new bug reports so I spent some time to fix those. Here is a quick review of the features I added support for this week.
This week most of my time was spent on debugging. My new machine is running fine, and now building WebKit takes a little more than an hour, which is much better than the 4 hours I was getting on the old laptop. With a 4 thread CPU machine some concurrency and locking issues became much easier to reproduce. This led to identifying and fixing a bug in our BSecureSocket class, which was not properly setting up SSL for thread-safe operation. I think this will fix most of the remaining memory corruption problems.
During the last two weeks, I spent most of my time working on the WebKit2 port. As I already mentioned, WebKit2 is where current WebKit development happens, and the most important change is the split of the WebKit system into two processes, one for showing the window, and one for doing the actual work of rendering the pages. But the more interesting thing is the more up to date and full-featured API that lets WebKit handle, for example, HTTPS certificates, so we don't have to do it ourselves - just show the dialog to the user when told to.
This week most of my time was spent working on getting WebKit2 compiling on Haiku. WebKit2 is the new multi-process model for WebKit. It replaces the old WebKit1 that our port uses currently. WebKit2 spawns a new process for each tab, and possibly more (for network access, etc.). The key features are:
- When a webpage crashes WebKit, only the tab showing this page is lost, not the whole browser
- The use of more processes makes the application feel more reactive. As you know, the threading model in WebKit is not a perfect fit with Haiku's one, but splitting things in a separate process allows us to have a standard Haiku application as the visible browser shell
- All the tricks of getting WebKit running (specific tweaks to BApplication and BWindows) are moved to the rendering process. This makes the BWebView API much simpler, as it will become just a plain subclass of BView, with no expectations on the BApplication or BWindow
- The WebKit2 API is where all current WebKit development happens. WebKit1 lacks support for some features
The quest to provide a better web browsing experience continues this week with some small fixes which result from hours of tracking down bugs.