Port PaleMoon to Haiku?

We only need libunwind and jemalloc to be able to build the non-GUI stuffs of UXP, this is also mean we are able to be build spidermonkey, Mozilla’s JS Engine, too. I have opened issue on the HaikuPorts, hope people would work on it soon.

The issue is here: https://github.com/haikuports/haikuports/issues/5138

@waddlesplash Please reopen this issue: https://github.com/haikuports/haikuports/issues/5132

I have opened a poll. I will close it on Monday. I want to check if people have to same interest as me. I should do it from the beginning. If I lose, I will stop asking you to port PaleMoon.

I closed the issue for a specific reason and you have given no reasons to reopen it, so it shall stay closed.

Everybody can vote, but who will do the heavy-lifting?

If this poll is useless, let’s just keep it open indefinitely. At least we could know the thoughts of many users there. The people are clearly favor focus on Web+ now. But who know if this idea will stand over time? It’s an interesting poll, at least.

1 Like

Over years, people keep coming with wishes. That is ok from the point of view of the matter, but mostly this are people who have entered into the community zero. They come as a new user and first make their wishes, which means for me that they have not really dealt with haiku so far.
This is not to be seen as an insult. I understand that who would like what there are used to, but this is a project that has grown over the years with many long-established developers and also many new helpers.
Wouldn’t it be fair to use and evaluate what was created instead of wanting to change everything first? Everyone is free to integrate, if you can program the better. if you cannot and want to support and promote something that is close to your heart, something that does not currently exist, you can try to motivate others to do so.
But I think to come back to this post that simply starting a survey for software that has never been discussed here before is not the way to go. For my part, I didn’t know the parle moon browser at all.

3 Likes

I did the original, rough port of WebKit to Haiku more than a decade ago. Believe me: it is much easier to fix our WebKit port and WebPositive than to port another big browser.

Obviously anyone is free to try to make a port of Chrome, Firefox, PaleMoon or whatever, but the core Haiku team will remain focused on WebPositive.

I believe we will eventually “catch up” so that WebPositive is as pleasant to use as Safari on macOS, which for me has been totally fine (I use macOS at work.) Safari is very good on power management and pretty fast, but yes, WebKit has not implemented all the stuff that Chrome keeps shoving in to the browser with their massively huge team. I think this is fine because it is starting to get ridiculous (WebUSB, really?) The goals Google has for Chrome to support ChromeOS do not always match what makes sense on a normal OS.

I believe things like ad blocking could be done in a “Haiku way”, like a really fast C++ implementation rather than relying on JavaScript browser extensions. But even with that said it should be possible to support the same JavaScript extension model as Firefox and Chrome, since they have essentially both moved to the same interface for extensions. Again, that should be much less work than porting Chrome or Firefox. But it is probably still quite a bit of work and there are more pressing issues like caching, improving rendering and moving our WebKit port to webkit2.

We need to get our WebKit port and WebPositive as nice as we can within the current limitations of Haiku (like no GPU acceleration, yet.)

I suspect that when Haiku is further along, or maybe after R1 is released, people will step up to port some of the bigger browsers. Though as has been said projects like Chromium may not be interested in upstreaming patches for “obscure” operating systems like Haiku, even if Google as a company has repeatedly invited us into Summer of Code :laughing:

10 Likes

This doesn’t make much sense. WebPositive is far worse than Safari today, and Safari improves faster than WebPositive. It’s as if you propose that although your car is slower, and you’re behind, you will soon catch the other racers because you really want to.

A really nice example came up recently, the next Safari (in preview now) will treat Face ID and Touch ID as factors for a platform authenticator. So you can sign into web sites by just touching the sensor on a MacBook (or looking at the camera). That’s a big improvement simultaneously to security and to ease of use.

Which parts of that work in WebPositive? None of the component parts are there, none of the preparation, and there’s no ongoing effort to deliver this. And this wasn’t even a headline feature, it was buried under “Security features” in the Safari release notes.

For GSOC Google are mostly concerned that there should be a pool of mentors, it isn’t important whether the project “contributed to” actually makes any sense because the students are learning how to work on a project not which projects are worth their time. Definitely don’t mistake Haiku getting GSOC invites for “Google thinks Haiku is a good idea”.

So, another party will own my face ?

Good points.
But to suggest to port a new Browser ist like… saying … your care is to slow… lets resamble a complete new car but therefore create new parts… good point… so i better go with the slow working car and look how to make it faster.

The Face ID integration in Safari has not so much to do with the browser and not so much with webkit… ist not a browser features… its a OS Feature bound into the Browser. So if this feature exists in the OS … it is kind of the integration like a password manager into the Browser…

Your Apple device would need to have a record of your face for this to work, yes. That doesn’t seem like “another party” to me but of course it isn’t mandatory.

I think using WebKit is the problem here. I mean, surely if we used another engine we wouldn’t need working webcam and fingerprint scanner drivers to make it work then?

WebKit progress is slow because there are many missing parts in Haiku itself. Porting another web engine instead will not help with that, the underlying problems will still need to be solved: missing drivers, performance problems in the TCP/IP stack, in the app_server drawing code, limitations of our font rendering support, …

In terms of WebKit itself we are usually a few month behind the current WebKit development, which is not so bad and probably on par with Safari (since they don’t make a new release of it every day).

6 Likes

Haiku’s Webkit snapshot is more recent versus Safari 13.

Web+ has potential. As for Pale Moon, it is a nice web browser. Porting is optional.

I don’t think Haiku can compete with Apple and we aren’t trying to. Safari was just an example of a fairly decent WebKit-based browser which WebPositive could in theory be somewhat on par with, eventually, as opposed to porting PaleMoon. No doubt there is a long way to go. Unfortunately browsers have gotten more complicated than operating systems in some ways.

Haiku benefits a lot from the work Apple has put into WebKit and I do appreciate that. In my experience a lot of people dump on Safari and think it is a bad browser compared to Chrome or Firefox, but for me it has been okay, though I did switch to Firefox on my iPad.

TouchID and FaceID are not relevant to Haiku and adding support for that to the browser doesn’t sound like some great accomplishment.

But overall trying to compare Haiku to Apple, a trillion dollar company, is just absurd. Given our resources, I think Haiku has done okay. And even with their resources, Apple kind of botched Catalina, and the new Music app is a bug-filled joke. Software is hard, and even billions of dollars can’t always make it work.

5 Likes

It’s a “pleasant to use” platform authenticator. So it ends up that using Safari is much more convenient and secure, even if Haiku has the very latest build of WebKit. This exactly contradicts what you believed will happen. Safari gets more pleasant, WebPositive stays the same. That’s not how you “catch up”.

Beyond a certain point systems like Haiku should be required to carry interstitial warnings because I don’t think users appreciate how much worse their security is. Again I expect that problem to increase over time.

Haiku is not trying to replicate macOS specific functionality that Apple may choose to integrate in Safari. Understand that the underlying code base of Webkit that is utilized by Safari will continue to benefit Web+ as the Haiku port is improved, more bugs are squashed and more of the cross platform features are implemented in Haiku itself.

I don’t code, so I have no complaints about the progress that @PulkoMandy and others have made with WebKit on Haiku.

Aside from the problem of limited developer resources, I don’t see how any open source (or any browser not backed by a big organization, to be more specific) could support features like that. Correct me please if I’m wrong but as far as I know the whole matching of faces and fingerprints is done on Apple’s server infrastructure and not locally. If that’s the case how could a project with very limited resources like Haiku even think about implementing such features?

I don’t think so. You would be unable to unlock your phone after using “airplane mode”. So it is done locally.

3 Likes