is this still in the roadmap or post beta3 ??
AFAIK, it never was.
1 Like
There is no existing usable WebKit2 port, unless someone developed one without telling anyone? I have made some slow progress on getting WebKit2 compiling again, but that is far from complete.
There will be an update to our existing WebKitLegacy port. I have tagged the 1.8.0 release on our git repo, but I have not tested the haikuports build (or rather, I did, but I ran oout of disk space so that test isn’t really conclusive). When I have some Haiku time (probably this weekend) I will try to finalize this.
I expect this release will introduce fixed but also lots of new problems. I hope I will get some help in fixing these problems, and we can then have a version 1.8.1 sometime before the beta3 release.
11 Likes
Yes, you can find the sources of the haiku port at GitHub - haiku/haikuwebkit: Official Haiku fork of the WebKit repository and it is clearly marked as a fork of this official github repository.
Our port is based on the WebKitLegacy APIs because when it was started (in 2008 or so), WebKit2 was not mature enough and WebKit people recommended against using it.
Note that WebKitLegacy vs WebKit2 makes differences mainly in the APIs and in the process model (WebKit2 runs different parts of the browser as different executables). It does not change anything to the networking code or the rendering engine.
9 Likes
is webkit2 a significant improvement ? or just change for the sake of change ??
It’s for multithreading.
I successfully compiled Webkit 612.1.21 on Haiku R1B3 x86 based on the recent haikuwebkit 1.8.0 patches.
Needed to rebuild WebPositive afterwards for it. Otherwise,we can compile the latest Webkit 612.1 ‘release’ (i.e. Webkit 612.1.21) on Haiku R1B3.
Webkit 612.1.21 x86 build link:
7 Likes
they designed a nonmultithreaded browser originally ? wow, that was short sighted
Well its origins were from way back (KHTML and khtmlw).
Pretty much all browser engines used to be singlethreaded.
When this was created rendering web pages was way simpler 
It allows running a separate process for each web browser tab. The idea is that if one website freezes or crashes, it doesn’t bring down the complete browser. It also provides some sandboxing and can avoid one website peeking at the data of another.
There is, however, a performance cost to this. We will see how to configure it and try to find a good compriomise.
In webkit, the “legacy” API that we are using is currently maintained only for old iOS apps which are using it. As a result it does not expose some of the new features like ad blocking. It is also not really a cross platform API, basically each webkit port has (or had) its own implentation of this layer. WebKit2 will allow us to share a bit more code with the other ports.
8 Likes