My progress on WebKit2 port

brunobastardi · December 11, 2021, 6:30pm

This thread is about Webkit2 progress!
Firefox and Chrome does not uae WebKit!
Haiku is working on own native webbrowser which use WebKit!
Webkit is used and very successfull on Macintosh Computers!

X512 · December 11, 2021, 6:34pm

Mobile Safari is most troublesome browser I even experienced. Even WebPositive and Internet Explorer works, but iOS Safari doesn’t.

the_webers_inc · December 11, 2021, 7:17pm

Thank you @PulkoMandy for you continued perseverance with Webkit/Webkit2!

Reformator · December 11, 2021, 7:22pm

The browser engine is not important to the user at all. Stability, rich functionality (various add-ons and a normal tab bar), convenience and moderate resource consumption are important for the user. All Haiku browsers do not meet these requirements. Except that moderate consumption of resources. But that’s the only thing browsers can do. And why use the system without the normal use of the Internet?

dcatt · December 11, 2021, 7:36pm

All web browsers are generally horrible because the WWW is an incompatible mess in general.

https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html

leavengood · December 11, 2021, 7:59pm

I believe we can get most of the good functionality of other browsers with WebPositive. With some work the tab interface can be much improved, support for add-ons can be added since both Firefox and Chrome have converged on the same general add-on API, performance and stability will be improved, etc.

If you have more details about what WebPositive lacks for your use case and can list some out, that can give some ideas of things we can work on. Of course many of your issues are probably already known.

It is enormous work to port a browser. This has been discussed here probably 100s of times. The code for almost all the browser engines (not including the actual browser itself, just the engine) is much bigger than all of the code for Haiku, including all our native apps. They are massive, and they get bigger every day as Google attempts to put anything they can think of in the browser API (WebUSB, WebBluetooth, WebGL. WebToaster and WebCar probably coming soon!)

Google is actively hostile to ports of their Blink engine to other platforms beyond Windows, macOS and Linux. Probably because they know it is a ton of work and they don’t want to pay engineers to help maintain obscure (to them) ports.

The chances are low that anyone else outside of the Haiku project will be able or willing to port Blink/Chromium or Gecko/Quantum/Firefox to Haiku. Of course some people have made some progress on QtWebEngine which uses Chromium so there may be some hope, and of course more browser options is good, but for quite a while it is doubtful Haiku will ever get Chrome or Firefox or Edge or Brave or another well known browser. For now it makes sense for people on the Haiku team to focus on our WebKit port and the WebPositive browser.

nephele · December 11, 2021, 8:07pm

On a more happy note I have started to upstream some of our webkit work (one patch for now), if all goes well I can upstream quite a bit more which should reduce the work needed for rebasing our port and make our port more robust in the long run.

Exiting times for haikuwebkit I would say

leavengood · December 11, 2021, 8:13pm

Awesome news! Thanks so much for stepping up for this nephele! Also thanks to PulkoMandy for many years of work keeping the repo rebased.

I greatly regret that I wasn’t able to stay on top of that and our original port got removed from WebKit. Hopefully now with more people helping we can keep it properly maintained. At some point I’ll join in to code on this again…

X512 · December 11, 2021, 8:17pm

Isn’t it required automatic build server for Haiku to test builds as requirement of including Haiku code in upstream?

nephele · December 11, 2021, 8:24pm

Sounds like a chicken and egg problem to me, the patch I have submitted so far is not directly haiku related, though it fixes an error that affects out port, for further work I will clean up and submit the port in smaller parts. When upstream wants a builder and we have a target upstream that can be build by one the sysadmin team can set up a builder then I think.

leavengood · December 11, 2021, 8:34pm

I can guarantee Haiku, Inc will be up for funding a new builder, if needed, to support upstreaming the WebKit port. Of course I think some people have volunteered some servers or home machines for this which might also be an option.

PulkoMandy · December 11, 2021, 8:49pm

Not formally required, but it would help them make sure they don’t break it when making changes. If that works out, it means I don’t have to spend as much time fixing all the build issues and merging changes, and I can instead focus on other possibly more interesting things.

But before we get there, I think some part of the changes can be merged without a lot of problems, starting with the low-level code for platform abstraction, and all the parts where we just need a “|| PLATFORM(HAIKU)” added to a #ifdef check. These don’t really need extra testing.

SCollins · December 12, 2021, 3:26am

I’ve got a few older amd systems, I’ll dig through my pile and see if i have a complete pc i cam donate

amonpaike · December 12, 2021, 4:50pm

A few years ago, I had sympathy for Google for their openness to open source, but for how they have recently become, for too much invasiveness, and for the totalitarian surveillance policies that suffocate individuals, I am almost glad that chrome/ium does not set foot on HAIKU.

PulkoMandy · December 12, 2021, 7:34pm

Today I investigated the crashes. The first one I had was really easy to fix: I had enabled fullscreen support as a test but the code is not written yet, and returns an uninitialized pointer, resulting in a crash.

After fixing this… I hit another crash

This one is a bit more complicated, it happens in the setup of communications between the different processes used. Currently the code tries to use BLooper and BMessage for communication between the processes. For this to work, creating a connection requires knowing the PID (team_id) of the process to communicate with. But the code for inter process communication in webkit does not work like this. Instead it expects to create a “connection” (for example in linux this is a posix socketpair) and then send a handle to this connection to the other process.

I am trying to find a way to make things work without changing too large parts of the cross-platform code (as long as our code is not upstreamed, it is easier to try to fit the existing architecture). One option is to stop using BMessage for these communications, and use posix socketpairs like Linux. But it creates some extra complexity: at least the process with the UI will still need a normal BApplication loop, and it’s currently not easy to handle both that and the posix sockets in the same thread.

leavengood · December 12, 2021, 8:39pm

Could you send the port_id of the main BApplication to the other process to establish communication? How is the socketpair communicated on other platforms, as part of the command-line when launching the other process? Could that be done with a port_id too?

Edit: Well might as well just send the team_id in that case, though it must not be this simple or you would have just done this. But it feels like something has to be used to pass the communication channel.

leavengood · December 12, 2021, 9:04pm

In my old experiment for multi-process rendering I passed the team_id of the main app in the BMessage used when launching the rendering app.

github.com

leavengood/Haiku-Browser/blob/master/Tranquility.cpp#L56

    
      
          }
          
          

          
void
          Tranquility::ReadyToRun()
          {
          	fBrowserWindow = new BrowserWindow();
          
          
	be_roster->StartWatching(be_app_messenger, B_REQUEST_QUIT);
          
          
	BMessage startMsg(kMsgStartRenderApp);
          	startMsg.AddRect("renderFrame", fBrowserWindow->Bounds());
          	startMsg.AddInt32("teamID", be_app->Team());
          
          
	team_id renderTeam;
          	if (be_roster->Launch(kRenderAppSignature, &startMsg, &renderTeam) != B_OK) {
          		BAlert* alert = new BAlert("Error!",
          			"There was an error trying to launch the render process!", "Damn!");
          		alert->Go();
          	} else {
          		fMessenger = new BMessenger(kRenderAppSignature, renderTeam);

github.com

leavengood/Haiku-Browser/blob/master/renderboy/RenderBoy.cpp#L82

    
      
          		case kMsgStartRenderApp:
          		{
          			BRect renderFrame;
          			if (message->FindRect("renderFrame", &renderFrame) == B_OK) {
          				char str[100];
          				sprintf(str, "RenderBoy: got a renderFrame (%.0f, %.0f, %.0f, %.0f)!",
          					renderFrame.left, renderFrame.top, renderFrame.right, renderFrame.bottom);
          				syslog(LOG_DEBUG, str);
          				fRenderFrame = renderFrame;
          				team_id browserTeam;
          				if (message->FindInt32("teamID", &browserTeam) == B_OK) {
          					sprintf(str, "RenderBoy: got a browser team ID of %d", browserTeam);
          					syslog(LOG_DEBUG, str);
          					status_t error;
          					fMessenger = new BMessenger(kBrowserAppSignature, browserTeam, &error);
          					if (error == B_OK)
          						// Only set this if everything needed was received correctly
          						fStartMsgReceived = true;
          					else {
          						sprintf(str, 
          							"RenderBoy: could not create a valid BMessenger to the browser, error was %d!", error);

PulkoMandy · December 13, 2021, 7:26am

For the main application it works fine already (in one direction by passing the process id as an argument, in the other by sending it in a message after starting). Now my problem is creating the connection between WebProcess and NetworkProcess.

What webkit tries to do is:

main process creates both of these
it sends a message to NetworkProcess, telling it to create a new connection channel
networkprocess replies with an identifier for the channel (in our case this contains networkprocess pid)
main process forwards this identifier to webprocess

In this scenario, NetworkProcess never gets to know the webprocess id so it cannot initiate the communication with it. I think the simplest way to handle this is to modify the message sent from the main Process to include the process id.

It used to be simpler to do this in older versions of webkit because more of the code was platform-specific, but now they have factorized some parts of it which means a little less flexibility (or modifying cross platform code as needed)

steampunklolcat · December 13, 2021, 2:44pm

I would be extremely happy if I could have vertical tabs and firefox sync in WebPositive.

nephele · December 13, 2021, 4:12pm

It seems there is no ticket for this yet, maybe open one at https://dev.haiku-os.org so this doesn’t get lost.

Here is the ticket for firefox sync, feel free to upvote it: https://dev.haiku-os.org/ticket/16589