My progress on WebKit2 port

You can use Nitter to view Twitter content on a fast website without being tracked, without ads and without cookie banners.
See here: PulkoMandy (@pulkomandy): "@webkit WebKit2/non-legacy for @haikuOS compiles again and the MiniBrowser executable starts! It crashes when trying to load a page (not very surprising with the number of things left unimplemented) Let's see if I can d bug this now!" | nitter

4 Likes

What do you think this forum topic is? :smiley:

Twitter is a bit better for outreach, some people who don’t use Haiku or closely follow us will read it there. Forum is better for the Haiku community, and for collaboration and technical discussions if needed.

So I did both.

10 Likes

I just find inconvenient that opening bloated Twitter is required to see photo.

5 Likes

Just use one of the gateways like nitter

@webkit WebKit2/non-legacy for @haikuOS compiles again and the MiniBrowser executable starts!
It crashes when trying to load a page (not very surprising with the number of things left unimplemented)

Let

1 Like

I tried to link the photo directly from twitter but it didn’t work this time (strange because it worked in previous times where I tried to do this). Not avery exciting photo anyways, for now…

Anyway, status update: I have now pushed this work to the webkit2 branch on github if other people want to play with it. I have extracted some fixes to put in the main branch too (doing this by small pieces and trying to make sure all commits that go there are properly tested and safe to include in webkitlegacy version).

I will resume testing and debugging tomorrow!

13 Likes

6 posts were split to a new topic: “Twitter is a propaganda ministry”

Hello. I would like to know if Chromium or Firefox browser will ever be ported to Haiku? Browsers that have already been ported are inconvenient and unstable and have limited functionality. I like Haiku, but to use it, the browser must be fully functional and stable.

That’s a question to Google and Mozilla.

However, Google doesn’t accept patches for OSes other than Windows, Linux, Mac and Android, so IMO there is no point in trying to port Chromium.

3 Likes

Thank you, then I will wait for otter browser to be stable and fully functional

I place my bet on @PulkoMandy to get Web+ there first.

6 Likes

WebEngine, Blink and Qt-based browsers is probably easier target. It will work almost perfectly after fixing Javascript engine crashes.

7 Likes

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!

1 Like

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

1 Like

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

5 Likes

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?

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

1 Like

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.

19 Likes

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 :slight_smile:

19 Likes

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…

11 Likes

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