Haiku Native Browser and WebKit port progress

Blog post by maxime.simon on Fri, 2009-06-19 20:34

After a month of work, it's time to take a break and a step back to check on our progress.
And after a month what we have is a prototype of a multi-process browser.

Haiku Native Browser

Ryan and I had a dilemma: Where to start? In fact, there is a lot to do on this project.
So we decided to start with a multi-process browser prototype.

When I arrived on the project, Ryan had already started and had created an application that displays a bitmap rendered in another application. ( You can easily see here the basic architecture of a multi-process browser, a rendering engine detached from the browser. ) I had also made a similar prototype, but as Ryan's one was most advanced (especially the bitmap renderer), we began to develop the prototype based on his work.

Our work up till now:

  • diverse forwarding from main process to render process (mouse move, mouse click…)
  • a bookmarking library
  • a toolbar
  • support for multiple rendering processes
  • tab management

You may easily guess that we divided these tasks.

I was in charge of desiging and implementing the bookmarking library. I tried to make something like in NetPositive. In fact this work was finished at the end of May. :)
For the toolbar, I did some research and found that the toolbar from the walter library is pretty good. That was the first implementation we did. After a while I tried to add a text field. At that time I had to abandon the walter toolbar. Indeed it was easier to design our own toolbar than integrating a text control box. But we keep the walter library for the buttons in our toolbar.

 a simple toolbar and a bitmapHaiku Browser Prototype (aka Tranquility)

As you can see the icons are far from beautiful but they are temporary. (Any constributions or ideas from a graphic artist are welcome.)
As we liked the menu bar background in Haiku, we used the same for the toolbar.

Since Ryan made the basic structure of the browser (renderer/browser), I designed the multiple rendering processes support, so that I can decently understand how our prototype works.
I had fun designing a sad tab à la Chrome. When a RenderBoy (that's the name of our rendering engine) quits, the browser (or browser tab when tab management will be complete) displays a 'sad tab' bitmap.

Tranquility - Sad TabTranquility - Sad Tab

As for the forwarding from the main process to the render process, it was Ryan's job. And he did well using BMessage. And what about tab management, Ryan is currently working on it. And I'm pretty excited to see what he will come up with.

WebKit port

We have reached a point where work on the browser prototype can't really progress (improvements will be done later, but none of them is enough important for now), and it is time to consider porting WebKit.

So, for a week now, I've been trying to build Webkit. It doesn't matter if it works (or not) for the moment.
In fact, WebKit is divided in two main parts:

  • JavaScriptCore
  • and WebCore

( the repo contains much more code for test purpose, website, and other platforms support ).

And we can easily divide my work in three parts:

  • get JavaScriptCore to build
  • get WebCore to build
  • get all this stuff to link

The first task was in fact the easier. The JavaScriptCore code is rather platform independant, so it didn't need a lot of work to make it build.

The second was a bit harder. WebCore is indeed much more platform reliant. Thankfully, Ryan did some good work with his last Webkit port. And I can easily reuse his code. In two years the WebCore code has changed, but not so dramatically. And I finally succeed in building it.

The third part… is the third part.
I'm currently working on it. And I avoided a lot of “undefined reference to”, but not all of them. ( Linking around 1300 objects isn't such an easy task. ) So I hope to finish this very quickly, to keep things moving.

What now?

We still have a lot of things to do:

  • make WebKit work ( some essential functions specific to the platform have to be implemented ),
  • integrate it into the browser,
  • port the Chromium networking code ( this could be an article on this blog. ),
  • improve the back and forward buttons,
  • create an omnibox-like url field,
  • and other mysterious things…

Comments

Re: Haiku Native Browser and WebKit port progress

Finally, 2 or 3 hours after writing this article I managed to fully build WebKit. ;)
Now let's started to try making it work.

Re: Haiku Native Browser and WebKit port progress

This is indeed an exciting project!

I can't wait to use the fruits of your labor :D

Re: Haiku Native Browser and WebKit port progress

Great news! Keep up the awesome work!

Re: Haiku Native Browser and WebKit port progress

Good work;)

BTW. Tranquility? - no way...

Re: Haiku Native Browser and WebKit port progress

“Tranquility” may or may not be the definitive name. It was just Ryan's favorite, and as he started to develop the prototype under this name we keep it for the moment. So, it could change. :)

Re: Haiku Native Browser and WebKit port progress

I cross my fingers for "Hawaii" :)
Great work so far Maxime, keep it up :)

Re: Haiku Native Browser and WebKit port progress

Maxime has been doing a great job on this project. It is nice to feel like I am not the only one working on it consistently (I had some help on the last port toward the end, but not for long.)

As for the never ending saga regarding the name, Maxime is correct in that I just started using Tranquility for the prototype. As he says the name may change, but I want to get some nice working code going before getting back into the naming issue. After some thought I realized naming non-existent software was sort of putting the cart before the horse, as the English saying goes.

As for the tabs, I hope my work is as good as Maxime expects it to be. I mostly plan to clone the Chrome tabs, which I think work quite nicely.

It will also be nice once we have the basic WebKit port working again, as their is a lot of neat little stuff to do for that.

Hopefully by the end of the summer we will have something nice to show.

Re: Haiku Native Browser and WebKit port progress

What is your opinion on Google's V8 javaScript engine?

Is it something to test after GSOC or....?

Re: Haiku Native Browser and WebKit port progress

V8 JavaScript engine is a possible alternative for our browser.
But it isn't part of the WebKit port. And for the moment we would like to have a fully functional browser and it's simplier to use JavaScriptCore (as it's better integrated in WebKit).
So, except if I have extra time (which I'm pretty sure I won't have), it won't be part of my GSoC program. But why not after?

Re: Haiku Native Browser and WebKit port progress

Excellent! Great work guys, keep it up!

Just one thing , though... I know it's a prototype but... why are the back, forward and reload/stop button at the left of the window? NetPositive's placement is better IMO.

Re: Haiku Native Browser and WebKit port progress

Good question… :D
The toolbar is something which would need improvments in fact.
But IIRC NetPositive is the only browser which behaves like this.

Re: Haiku Native Browser and WebKit port progress

BiPolar wrote:

Excellent! Great work guys, keep it up!

Just one thing , though... I know it's a prototype but... why are the back, forward and reload/stop button at the left of the window? NetPositive's placement is better IMO.

I have thought about that some and tend to think keeping with the design from other browsers makes more sense. For one thing consistency with other browsers is not a bad idea, for another Fitt's Law would indicate to me the back and forward buttons (likely the most used buttons on a browser) should be closer to a corner. The NetPositive ones are pretty hard to hit compared to when they are on the left.

Though in general I think configurable toolbars are a bad idea, we could consider allowing the buttons to be moved to the right of the location bar to emulate NetPositive. But the default will probably be like you see.