The goal of this document is to be an overview of everything I did during GSoC. It should be readable even if you haven’t read any of the previous blog posts and don’t know much about Haiku or WebKit (I hope I succeeded!).
Ahoy @Zardshard !
Reading summarized this journey … you don’t have to blame yourself.
You arrived JIT 
Me, who gathers browsers on Haiku, I do not do this as I am not satisfied with Webpositive at all, in the contrary :
→ I use Web+ for reaching all Haiku specific services. I am happy that more important Haiku links are available bookmarked from first install. Haiku services dos not requires adblock or malware blocks - thankfully , so I do not miss it,
For Video playback I can use another ported browser if it needed.
Another reason - I do not use one browser for all net activities – I like to separate the kind of actions I do in a specific browser. This way I use at least 2 or rather 3 browsers simultanously.
So if Webpositive would be able to do anything that possible in 2024, I would only use it for Haiku specific stuff, translating texts with Google or else and visit my Haiku related mailbox.
For entertainment and a bit risky sites where my curiosity drops me sometimes I use another one …
And for financial activitis a third one.
What I will appreciate primarily from your work is … *** massive stability*** -
I mean that, sites won’t crashes Webpositive totally in the future, but only the “tabs” - if so any happens at all.
For me - it will be the biggest improvement related Webkit2 implementation and its API usage in Webpositive.
In your report I found only one sentence which is a bit surprising
- Our WebKit2 API for applications to use needs to be improved. The API that currently exists is a bit messy.
Applications means : Minibrowser and Webpositive – in this case ?
What other applications … if any ?
Kind regards,
Any application that wants to use WebKit2. Currently its only MiniBrowser, but hopefully WebPositive will be using it in the future 
Application/Mail, Offline documentation reader. etc.
Right, it’s clear this way – for me it was strange
what would use an internet browser’s engine as an app ? …
Of course any (internet) browser.
Somehow , sometimes as an end user I forgot about IT standards.- so I look at an application , a one block , meanwhile there are swappable parts. And those parts - in the deep - with development … can be used for other purpose.
This way popped up … what else would use WebKit 2 ?
And then , it’s flashy momment : Ah OK, browsers are finally apps as well from another perspective, but sorry for first time it was too obvious for me to engines and browsers are belonging to each other … this way I handled them together and not alone as another ‘application’. Ok I finished to explain my logic.
Ok, so
→ the better engine WebKit2 (in haikuwebkit) which can be built-in anytime (soon ) : now improved a lot by your and mentors work ,
→ but the “cabling” (WebKit2 API – in haikuwebkit) must be redesign and rebuilt , before start to fit to Web+ – using Minibrowser as a “testcar” if I understand well.
A bit more on “what’s next” from my point of view:
First of all, thank you for this work, which I was not able to figure out on my own since 2019, despite spending a lot of time trying to clean up the existing patches and experiment to try to better understand them. Now that we have a mostly working base with cleaner code, I hope it will be easier to keep that working.
During the summer, I paused the merges of upstream code, to avoid trying to build the webkit port on shifting sand. Now I will probably resume that and cach up with all the upstream changes. Usually I merge them in the webkitlegacy branch, and then rebase the webkit2 branch on top, that preserves the webkit2 commit history. And then I try to rewrite the history of the webkit2 branch to avoid places where code is introduced and then removed again to use a different approach. Once a part of the webkit2 branch is clean enough and tested, I integrate it in the main Haiku branch.
I’m not sure if I should continue doing it this way, or just merge everything and move on with a single branch.
After that, I think it’s time we start considering to upstream our changes again to WebKit. I have been maintaining WebKit for 10 years now, so, clearly there are some guarantees that the project will not be abandoned. But this means extracting all our changes in smaller patches that make sense and can be reviewed by WebKit developers. And I think they wouldn’t want to merge the WebKitLegacy parts.
However, while I work on all this merging and rebasing and upstreaming, I will not work on other things, including efforts to get WebKit2 more completely working. So, I hope other people can join and help with that
Awesome, thank you.
A big thanks here also! You’ve done an amazing job catching up on previous attempt, hope you can stick around some longer and iron out some missing parts.
A big thanks to you also @PulkoMandy for keeping this all in gear for all these years!
Big thumbs up to all involved! 
Of all the browsers that I have used so far on haiku, except webpositive, I am not satisfied with any other browser
I haven’t said anything about browsers, that’s not what this topic is about.
So, what am I planning to do next? Well, I’m working on a blog post with some information that might be useful for future contributors. Maybe I’ll also be able to add more comments to the code. Alas, I don’t have much time for Haiku anymore, so it may be a while till I finish with them.
How is going with the post-GSOC work on WebKit2?
I am cleaning up the patches and I have started upstreaming some things in WebKit.
Is there anything we can do to help? And to speed up the transition of Web+ to WK2?
I for my part am still working on that blog post, little by little, and hanging out in IRC from time to time.
Do you mean with the coding? One thing I think would be relatively easy is adding keyboard support. I can give you an outline of what needs to be implemented where because finding the files and functions on your own can be tricky.
Anything is helpful compared with nothing at all. Because the lack of guidance doesn’t help newbie coders.
Hence the blog post 
.
But I don’t really want to make an outline if I don’t know that someone is going to use it. I don’t have a lot of time after all 
. But, I’ll give this hint: Here is how mouse support was implemented. Keyboard support will tend to parallel that.
Well, I have decided to let the content of the blog post I was making be put onto WebKit’s wiki instead. So WebKit/Overview – Haiku and WebKit/WK2Processes – Haiku have been expanded.
Formatting is a bit messy, but I can’t edit the wiki, so it’s stuck that way for now, unless somebody fixes it…
Nice move! Blog articles are fun to read and can be consumed casually, but it is harder to keep it updated.
Living documentation is much better than that for longer timespan. Though it may be less frequently updated future, it should be easier others come and fix incrementally!