Diving into WebKit
First of all, I want to thank Haiku, Inc. for giving me the opportunity to concentrate fully for a while on the WebKit port and browser! This is an awesome chance that I intend to make full use of.
At the moment, I have mixed feelings. Not about writing blogs. Not about working on WebKit. But about using the new WebKit browser to write the blog entry, haha! I’ve seen it crash, although in the last days, it has become pretty stable. After we upgraded to a newer WebKit version as the basis for the port, the frequent random crashes have almost disappeared and I saw only one crash in three days. Compared to one every few minutes before.
But still, I am of course pushing it a bit by eating my own dog food so early on. Lucky for me, I have integration with the system clipboard already working, so I can at least copy & paste my writing into Pe from time to time.
I’ll try to give an overview of how I came to work on the WebKit port and what I’ve done so far. Basically, I woke up one day and thought Haiku really needs a modern, efficient and well integrated browser - now. In the beginning it wasn’t clear to me yet, what the best approach for this would be. I started out with NetSurf and looked into that port. Francois has done some solid work there, but the flickering annoyed me and I’ve looked a bit into how this could be fixed. At the same time, I tried a few websites and it just wasn’t convincing to me that NetSurf would be a full featured browser soon. It’s certainly an awesome project, but it looked to me like it’s not in the same advanced state as other engines. So I’ve started to consider Firefox and WebKit. For Firefox, I’ve heard that the problem is the Cairo port for Haiku. So I’ve downloaded the Cairo source tree and pretty much rewrote the BeOS port under the presumption that the existing Cairo software rendering backend could be used to draw into BBitmaps to get an instantly fully compliant implementation. Then however I failed to get the Makefiles set up correctly for building the testing framework. At the same time, it became clear through talks with Fredrik Holmqvist, that porting a current Firefox would be much more work than just porting Cairo to Haiku.
So WebKit began looking more and more attractive. I’ve quickly learned that Maxime Simone was keeping the WebKit port updated since his work on it during the Google Summer of Code 2009. I checked out the repo and began working on getting it to compile. Maxime was stuck at some linking problems, but after a while I figured out what those were and then Maxime helped me get the rest of the port into compilable state again. After I finally looked at the HaikuLauncher, which is the testing application to embed a WebKit view into an application, render a website for the first time, I’ve been working on the port and the browser ever since.
Work had and has to be done in all three parts. Some stuff was already finished from when Ryan worked on the port, other things were finished by Maxime, but a lot of the code was still stubbed out. Lucky for me, the port also consist of it’s own jam based build system, which I presume Ryan wrote. It’s nice not having to deal with that as well. After I fixed and implemented a great deal more code, HaikuLauncher became somewhat usable for surfing, and more people began to be excited about the WebKit browser. Michael Lotz has been crucial in tracking down some hard to fix memory corruption bugs and in extending the CURL network layer backend in WebCore to support htdigest authentication. Rene Gollent has implemented FileChoser support and tabbed browsing in HaikuLauncher. It was of course very encouraging to get support from so many people. Each day, the browser became more usable. And sometimes fixing one little thing, even if it was very hard to track down, can suddenly enable a whole bunch of websites.
So far I think my choice to invest into WebKit was a good one. It’s possible to make a very native feeling browser, although some compromises have to be made. While WebCore is essentially single threaded, at least the native drawing happens in one app_server thread per page. And this will of course improve over time, as WebCore itself will make more use of threading. In terms of feeling native, I believe HaikuLauncher has left the Firefox port far behind. It even renders faster in many situations, sometimes drastically faster.
Today, I’ve finally found the problem with frames and iframes not being loaded and you can thank Ingo Weinhold and praise his source level debugger for that. This too made a great deal of sites work suddenly, like maps.google.com, the full version of mail.google.com, www.gmx.net finally works… and I’ve found the cause of some annoying clipping problems. If you want to give the HaikuLauncher a spin, you need to run a GCC4 or hybrid Haiku system. And it needs to be pretty recent, since we’ve also fixed bugs and added features in Haiku to support stuff for WebKit and HaikuLauncher. Have fun! But keep in mind it can still crash. Just because I managed to finish this blog doesn’t mean you should trust it, yet. :-D
Download WebPositive (SVN revision: 444)
P.S. I’ve stolen the awesome icon from Meanwhile’s great BB icons package.
- [GSoC 2017] Porting Swift to Haiku - Week #9 / #10
- Recovering from RMLL 2017
- [gsoc_2017] tcp optimization report 5
- [GSoC 2017] Calendar Application: Weekly Report 6
- Haiku monthly activity report - 07/2017
- [GSoC 2017 - BTRFS write support] Week #9 #10 #11 (Second coding period)
- [GSoC 2017] Preferences GUI Refactoring - Weekly Report 5
- [GSoC 2017] Porting Swift to Haiku - Week #8
- [GSoC 2017] Calendar Application: Weekly Report 5