Fix QtWebEngine or work on WebKit?

give me a few days,I don’t have that much ram, but I will grab a cheap SSD and some ram and get this machine up and running. it is a older 8350 amd system with a piledrive cpu, but it’ll crunch code all day no problem.

1 Like

Although one should be free to spend his time on porting whatever browser he/she wants, we should focus on Haiku’s own browser, IMHO.
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. Much like what we have for Haiku itself. I may have missed that, though.

3 Likes

The tldr version is probably our tickets:
https://dev.haiku-os.org/query?component=^Kits%2FWeb+Kit&status=assigned&status=in-progress&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone

If you think any of these tasks interest you you can ask on the tickets for guidance, or info may be already there

1 Like

So, make a native port of Blink (HaikuBlink in theory)?

If so, then the Haiku-specific patches are unlikely to make it into upstream and they’d have to be maintained solely by Haiku. @PulkoMandy has mentioned in the past that upstream Chromium doesn’t really accept patches for supporting anything beyond Windows, macOS, and Linux. This is why the BSDs have to maintain their patches and have failed in upstreaming them.

In contrast, upstream WebKit does accept support patches for less mainstream OSes.

Agreed. HaikuWebKit is in a better shape than the result of those other browser engines, that would need a lot of compatibility additions to work, and with these additions not being supported by those browsers, as said in this thread.

And as people also said, what good in having another half-working browser ? It would be more fruitful to organize work in documenting / restructuring what we already have, and planning the necessary changes / improvements.

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).

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.

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.

5 Likes

this would actually be a solid argument as to why Haiku maybe should consider using the entire Qtwebengine backend, it is actively being developed. Has a significant commercial funding process, and I would imagine could be made more native. IIRC a lot of the current webkit port was done when QT used the webkit backend, that has diverged however. There is another way to look at the current state of the haiku webkit, it is just a Safari clone.

At some point the question becomes, what is the most beneficial and productive use of developers time and where doe’s their interest reside. I think finding a way to make a native implmentation, maybe not a port of the QtWebEngine might be better for the project in the long haul. IE convert it all to BeAPI naming and conventions and make a patch set to convert functionality where possible and extend where it isn’t.

Growing the BeAPI here is the key, and it can be kept in a private class until R2. But leveraging a massive well developed code base only benefits haiku with it’s very limited developer pool.

Assimilation of outside code into native code where it makes sense is probably the only realistic way forward unless all of us step up and fund haiku with several Million dollars a year in funding. If I thought enough people were onboard I would probably be willing to contribute at least $50-75 per month, but no point in my doing that unless enough people jump in.

At that however as my new business is slowly building momentum, I may in the future hire a developer or 2 to wokr on things I want done, that will include haiku.

I want a port of linuxCNC, without the linuxy problems, IE more like machine kit, I want FreeCad, with dramatic improvement’s to make it more like commercial products etc. Both of those things would be a not for profit enterprise but would probably require some kind of annual subscription fee of $10-25 a month or so " some adjustments to other currency’s country’s etc not withstanding" to spur real development of competing commercial vendor locked in products. Autodesk is on my last nerve.

I want those aps to use native or other well integrate APIS etc

That’s all a separate issue, I will get a PC build for the QtWebEngine building process and I will also set it up for remote access as a builder in general.

Isn’t it possible to increase userland address space to 3GB?

Qt uses Blink which is exclusively developed by Google.

On the other hand, HaikuWebKit uses WebKit, which is developed by Apple, Sony (for the Playstation), and Igalia (for GTK and also for WPE, which they use for embedded systems without a specific toolkit).
And also WebKit is welcoming support for more operating systems, while Google explicitly reject any of that. So we would be working against Google on Blink, not with them. Guess who would win?

That’s basically:

  • Get QtWebEngine
  • Delete all their sources, you don’t need them
  • Now get Blink from Google
  • And now you can start building your BeAPI backend on it

This is what we did with HaikuWebKit, except starting from WebKit and not from Google Blink. It took us 10+ years to get where we are with it. Personally I think it would be extremely stupid to throw this work away and start over with Blink, and spend 10 more years on it, only to hit the very same problems.

10 Likes

Honest question, is webkit capable of keeping up with the ever evolving stupidity of the web ?

That’s the information I was looking for, thank you!
I was unclear on where the WebKit2 development is happening.
Do you have plans to merge the two branches any time soon?

1 Like

As long as Mac and iPhone/iPad will be actual. Apple prohibit using non-WebKit browser engines in iPhone/iPad.

1 Like

i don’t think they have enough market share to have any significant impact on web development, more like they are trying to keep up. my thought is, who cares if the web rendering engine is upstreamed, is blink that hostile to porting ? I honestly don’t know

There is a reason for that. Although questionable, it keeps the iOS/iPadOS sandboxed environment mostly secure.
Don’t forget about Safari on MacOS, which currently is my favourite browser, btw. Besides some OS specific features, the engine is pretty solid, lightning fast and the memory footprint is smaller than Blink based browser.
I would say that, as long as there is Apple there will always be a WebKit. So I’m inclined to say that WebKit is the right choice, not Blink.
That is my personal humble opinion, of course.

5 Likes

They don’t prevent you from porting it, of course. The matter of fact is that they do not accept upstream patches for operating systems other than MacOS, Windows and Linux.

I would like to, but the webkit2 code and git history is not clean enough for my standards. Also, if the code is not working and no one is using it, it just rots in place and it will be very hard to find when it was working. It’s much easier to do that if the code is kept in a separate branch for now.

When it works, I think we will not take very long to move WebPositive over to webkit2 and delete the webkitlegacy code anyway, there’s no reason to keep it alive once the new version works.

5 Likes

That makes sense. Although I’m not a coding champion, I would like to help and will look into the WebKit2 code. Do we have a ML, IIRC or whatever (even Github itself) to discuss?

2 Likes

Irc (#haiku on oftc) or the development mailing list ( Mailing Lists | Haiku Project ) would be prefered for this (although the forum is probably “okay”), there is no webkit specific communication channel at the moment.

Specific changes can be discussed also on githubs code review, or on the bugtracker.

1 Like

Warning: Rant Ahead

I agree with the stupidity argument if you mean that having monstrously large web engines as a basis for a browser, just for compatibility reasons, is the greatest stupidity of the worldwide web. Modularity would have been better served as an engine made up of sub-libraries.

Unfortunately, starting over is not an option any more. When Mozilla tried to replace Firefox with Servo, their new and shiny Rust based browser, they found that even they couldn’t do it. Finally they ended up turning the code hosting and maintenance over to Red Hat. They are still trying to incorporate Servo’s code into Firefox over time using C++ bindings to Rust.

Once a Blink-based monoculture is established we fall into the same trap as we almost fell into with Micro$oft Windows in the 90’s. The only difference would be that Web Apps based on the Blink engine will not have the advantage of antitrust hearings to try to bust up the monopoly. Blink is maintained by Alphabet, sure, but isn’t the Blink source code an open-source licensed project? Just put a non-profit foundation packed with industry insiders as directors and trustees and the big tech trifecta of Microsoft, Apple and the Linux community will be complete in their internet dominance. Blink just can’t be a Haiku solution for the web.

A Way Out

While WebPositive is the current solution because it can try to piggy-back on WebKit2’s existing code base, we need another way out for the industry, and Haiku in particular.

A transition from Web standards to simpler ones could include dedicated internet applications. Do you remember when IRC clients weren’t written in JavaScript? When bulletin boards ran in text-based terminals? When NNTP clients on Usenet were many times more responsive than forums like this one? Those functions were well served independently of the browser.

My thinking is that modularity can make a comeback if we quit arguing about alternatives to WebPositive and start making alternatives to the protocols that require its use. Of course we’ll need to cherry-pick from among the existing protocols to find ones that work well.

Started a new thread for related discussion.

5 Likes

It must have been an earlier version, it was not on haiku though. I remember having trouble with it, but I last built webkit ~10 years ago. The first google hits suggests this was indeed true in 2012
https://forums.gentoo.org/viewtopic-p-7093866.html