Submitted by This is news that makes me very, very happy. Stephan “stippi” Assmus has written a lengthy blog post detailing the progress made on Haiku’s WebKit port, and they’re quite far along. Thanks to the help of several community members, the test browser, enticingly named (euh…) HaikuLauncher, is already relatively stable, supports tabbed browsing, and a whole lot more.
In the blog post, Stippi details just how he came to work on the WebKit port, and effort which has been under way for a while now. The progress he has been able to make, with the help of several other developers, is quite tremendous, and while I could try to summarise what it took to get there, it’s better just to read the whole thing yourself.
So, where does all this leave Haiku’s WebKit port?
“So far I think my choice to invest into WebKit was a good one,” Stippi summarises, “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.”
HaikuLauncher supports tabbed browsing, has a separate download window, and can render complex pages like Google Maps, GMail, and so on. Early reports from Haiku users (taken from the comments’ section) indicate that it launches fast, too. This is BeOS Haiku after all.
The website of the Italian Haiku User Group (a HUG! If that doesn’t fit the BeOS world I don’t know what does) has some very, very beautiful screenshots of the new browser in action.
Great! I hope that in the future the tabbed browsing will use the Stack&Tile implementation : http://www.youtube.com/watch?v=ccniJHjo_Uw#t=2m52s
There’s not really any benefit to doing that, Stack and Tile is more useful when you want to group together windows from different apps, it’s not a complete or suitable substitute for tabs within a window of the same app in all cases.
Why is it not suitable? It will be almost identical to the Google Chrome’s tabs – you can do almost the same tab manipulations between Chrome windows/tabs as in the Stack&Tile video. The ability to group together windows from different apps will be an added bonus.
Edited 2010-02-24 17:44 UTC
The most notable problem is that Stack and Tile is strictly user-initiated, ergo creating a new window or whatnot wouldn’t be automatically added to the existing tab group. The other problem is that the actual window tabs have to carry a lot more baggage than a regular tab view since they still need to have the close and resize widgets, and as such take a lot more space, meaning they’re less usable in a case where you want a ton of tabs, which is typically the case with a browser. Also, not everyone necessarily agrees with Chrome’s top-level tabs as they completely violate the UI standards of most OSes amongst other things.
Why should S&T be strictly user-initiated? Why shouldn’t there be an API that will allow apps to open new windows in tabs?
The close widget is available in Chrome tabs too, together with a favicon, so it should not take more space. And using the resize widget for every tab is not a good solution as it actually affects all tabs, so future S&T implementations should fix this.
There’s nothing different or special to opening many pages in tabs in a web browser, than for instance – opening many source files in a text editor.
And while top-level tabs may violate the UI standards of some OSes, if Haiku makes S&T a standard – this will not be the case.
Replying to this thread in the WebKit browser on Haiku is a lot of fun of course…
In any case, I agree what you’ve said about using Stack & Tile for the tabbed browsing. Ryan had this idea as well.
It needs a lot of work still. Stack & Tile is still not integrated in the Haiku source tree, since the remaining issues have not been fixed. And even if that were the case, the problem remains that there needs to be an API for this just like you propose. It should not only be user initiated.
This is such great news! These guys are on a roll, and more interest is being generated. I get a twinge of excitement thinking about the possibilities!
but yellowtab should have helped these guys by opensourcing their contribs.
“NetPositive with tabbed-browsing and a modern rendering engine” is a good description of the perfect web browser, IMO, so I’m quite eager to give this a try.
I hope HTML5 audio/video are in the roadmap for this browser in the near future. Lack of Flash is a major downside for an alternative OS these days, and that should be top priority to ease the pain a bit.
How much of that is done for you in Webcore, I wonder?
Edited 2010-02-24 22:10 UTC
Depends. Safari does not have built-in video decoding, it hands all of that off to QuickTime (which makes <video> in Safari no better than a plugin, with all the z-index and CSS problems that creates). Google strapped a decoder to Chrome so that it plays OGG and H.264 (but nothing else).
I would hazard a guess that Haiku would have to connect WebKit to the native media playback in Haiku themselves. As long as it has the necessary codecs then there^aEURTMs no real reason why HTML5 video shouldn^aEURTMt work.
Edited 2010-02-24 22:14 UTC
afaik video.google.com works with it already.
Flash is running about almost a year now.. the latest version released by two weeks ago (gnash 0.8.7) seems very stable! the only downside is FF 2.0 browser port, that is slow on Haiku. With this new Browser, is a matter of time build a new flash plugin with better performance.
The name, itself, doesn’t sound like a web browser (it has no web browsing or Internet connotation), but as long as it’s 100% standard’s compliant (passes ACID3 and earlier), I’ll be happy.
That name is simply a placeholder (most of the other testbed browsers in the WebKit tree were named similarly). The final browser’s name will be WebPositive.
No, it must be named after the Japanese word for “Internet” or “Web” or “Net”. Or maybe the Japanese word for “Net” and “Positive”, combined?
Edited 2010-02-25 00:11 UTC
And that would be “intaanetto” or “netto pojitibu”…
Okaaaay… scrub that thought… REALLY FAST!
How about the Japanese word for Web? And…
Adventure? Seeker? Journey? Viewer?
We gotta stick with the Japanese “theme” as long as it doesn’t sound… weird.
The name Haiku was chosen not because it is of Japanese origin but for the minimalism that it represents as a form of poetry, and for legacy reasons related to BeOS (the Haiku-formatted error messages in the Net+ browser). So there is really no reason to stick to a Japanese theme for everything in Haiku.
Anyway, from what I hear, the name of the new Haiku native browser has already been decided, and it is WebPositive.
Correct on all counts.
Just call it natto…
As long as it has the slogan “You should be working…” I’m happy.
Edited 2010-02-25 08:08 UTC
I’m sorry Sir, but you have tested positive for Web. We will have to quarantine you for the time being until an antidote is found.
Is that any worse than, “I’m sorry Sir, but you have tested positive for Net. We will have to quarantine you for the time being until an antidote is found.”
Still funny.
Edited 2010-02-25 07:26 UTC
Shame,”Hawaii” was a best option than WebPositive. :/
it’s really great to see how much progess haiku makes (compared to other “alternative/hobby operating systems”). I hope haikulauncher will be included as soon as possible in the nightly builds and hopefully gnash will be integrated soon in this browser.
it would be great to have google chrome on haiku, but I guess at this stage it’s too much effort.
I believe it will be close to Chrome but without extensions.
Edited 2010-02-25 10:14 UTC
It should be pointed out that WebKit and browser development can be supported by donating to Stippi’s contractual work on it (see http://www.haiku-os.org/news/2010-02-21_haiku_inc_hiring_funds_need… ). Imagining 160 hours of fulltime attention to the browser gives me goose bumps.
WRT to the name, let me introduce you to the all-time favourite thread: http://www.haiku-os.org/community/forum/name_suggestion_native_haik…
People really seem to put much concern in a name…
Regards,
Humdinger (who wrote this with HaikuLauncher. Yay!)
I’m very excited about all of the Haiku-related news I’ve recently heard and I have a few questions about this browser:
Is this browser based on Chrome? If not, why write a new browser from scratch? Does each tab run in a separate thread or a separate process?
Keep up the great work and I look forward to a day that I will be able to replace my Linux boxes with Haiku!
Chrome, no, WebKit (the renderer used by Chrome, Safari, Arora and a few others), yes. Porting the entirety of Chromium would very much be a non-trivial undertaking, and for being included in the OS we want a smaller/more lightweight browser anyways. Someone could certainly port the full Chrome later if they so desired though, and the work we’re already doing on WebKit would be required to do so anyways.
Currently each tab runs in the same process; running them in multiple threads has no real benefit, since a) WebKit currently requires all of its core actions to be executed from the same thread, and b) since threads share the same process/address space they offer no crash/security protection anyways, which is the primary goal of running them in separate processes. Multiprocess might come a little further down the road, but for the time being we have more than enough things to fix in our port of WebKit itself.
Edited 2010-02-25 19:17 UTC
Regarding running each web page in his own thread, the design taken by Stephan does it half : while the layout is done by webcore in one single shared thread, the rendering is actually done by Haiku’s app_server, which draw to every offscreen BView in a dedicated thread.
Multiple HaikuLauncher web view (tab or window, doesn’t matter) means multiple threads. But on app_server side…
I think this is a great project. Every user can benefit from a good and stable browser.
Good luck Stippi with friends.
With all of this wonderful progress, I hope this isn’t too OT. Alpha 1 was released in October. Now I know alpha’s, beta’s, point releases, etc. can be very arbitrary from project to project, but I was wondering about any word on Alpha 2?
I have an Acer Aspire One netbook that is screaming for Haiku, but is one of those infamous models that cannot find a boot partition no matter what you do. I’m hoping for a fix!
Read this thread for the latest discussions on R1A2:
http://www.freelists.org/post/haiku-development/R1alpha-2-time-to-g…
So obviously this is indeed good news, and Stephan, Michael Lotz, and Rene Gollent have done a great job continuing the work I started on WebKit and the browser.
In addition I’ve finally updated my Haiku development box to the latest revision and have been able to compile and implement some features in WebPositive, which I’m using for this post.
I added support for selecting tabs with Alt plus a number, as well as basic scrolling of the page with the keyboard. Of course I would not have been able to do this so quickly without everything else that Stephan and the others have done recently.
I hope to continue helping and will may take a look at adding support for HTML5 audio and video (though I can’t make any guarantees.)
— Ryan Leavengood