Fix QtWebEngine or work on WebKit?

[PulkoMandy]

@Munchausen

Well, the same thing is true of webkit to some extent. I believe 32 bit debug builds require more RAM to link than you can have in a single process on a 32 bit machine, for example, so you have to cross compile them on a 64 bit machine

No, you can link them, but you can’t load the debug info in Debugger.

But that’s a limit at 2GB of RAM, which is quite low by today standards, sadly. There is no need to jump all the way up to 128GB of RAM, with 4 or 8 you’re likely just fine. Or maybe we could rework Debugger to not load everything in RAM when it starts (it’s not easy to do, but it’s probably possible).

@SCollins

would it not make sense to borrow as much of the Qtwebengine as possible and make it native to the BeAPI in terms of extending the BeAPI and the native haikuwebkit to increase functionality ?

What are you suggesting, a kind of Frankeinstein monster using code from Qt, WebKit, and Blink and somehow mising it together?

There is no functionality missing in the backend of Haikuwebkit. It is based on the very latest WebKit engine, the same engine that runs Safari on thousands of iPhones, iPad and Macintosh machines too.

Really it just needs correct wiring to the Be API, in replacement of the hacky mess I put there because I don’t have time to do anything better. I just keep it up to date and mostly running, and I don’t have time to write the proper code for much of anything, so I go with the easiest solution. I think it is still useful to do this, because if I didn’t, people wanting to work with WebKit would have to start with the most boring and painful task: synchronizing our sources with the latest version of WebKit. So I do that part and keep hoping that other people will work from that up-to-date base and actually fix bugs, and not ignore my efforts and look into other web engines for reasons I don’t understand.

@Nexus-6

Is there a quick onboarding guide for who wants to contribute to the webkit2 porting? Something with the status of porting, areas that needs help, small easier tasks to start with.

For WebKit2, there is one big task to solve before we can do anything else: get it to start and get the several processes (webprocess, uiprocess and networkprocess) talking to each other using BMessage.

The README in the git repository is up to date with the current status. You can use this branch (named webkit2) for the webkit2 attempt: https://github.com/haiku/haikuwebkit/tree/webkit2
(last time I touched it was 5 months ago).

Or you can use the “haiku” branch if you want the latest “webkitlegacy” version, which is the one I at least try to keep up to date. Both versions use the same underlying web engine (besides the 5 months of missing updates in webkit2). The main difference is webkitlegacy runs everything in a single app, while webkit2 splits the work into several different apps. This allows, for example, to not freeze or crash the complete browser if something goes wrong. Only one tab at a time will suffer from problems.

If you decide to look at webkitlegacy, then indeed the list of tickets linked by Nephele is a good place to start, or you can just browse a few sites and find new and exciting problems to work on.