Why is that the case? Did something in Safari change with regards to rendering webpages? My guess would be that it requires an OpenGL surface, similar to Blink. Feel free to correct me on that, though.
No, it doesnāt need OpenGL. The drawing code is all our own and uses app_server. The issue is only with this specific website, so Iām not sure what is happening, as I see nothing special with it.
And if I knew what the problem was, I would have already fixed it. But I donāt know and Iām not sure how to debug this.
Well, another dependency needed to run the Firefox build system was Node.js and we have that too, so I guess that is one less dependency needed to run the Firefox build system?
Anyway, whoever attempts to build Firefox on Haiku will be forever* stuck on the GTK+ requirement check.
*Unless they port GTK+ or write a BeAPI backend for the widgets.
Yeah, we definetely donāt want to run Firefox in WebPositive.
Does Firefox actually use GTK+ widgets? Modern browsers renders all interface by itself. Chrome donāt even use native control theme.
GTK3 is avalible on Haiku, but without Haiku window system integration, only HTML5 websocket interface is working.
Iām afraid that this is the reality of attempting to upstream and support a new OS for Chromium-related projects. They will reject patches from other OSes, which is why the BSDs are maintaining most of Chromium patches themselves. So I find that āupstream supportā for Chrome or V8 is highly unlikely.
For example, the GN maintainers were very reluctant in upstreaming support for Haiku even when it passed all the unit tests. This was needed just to build V8 (Chromeās Javascript Engine). [0] Reason being was because we donāt have a CI for this, so I (unofficially) created one. If it was that difficult to upstream that, imaging about attempting to upstream patches for V8 or Chrome support for Haiku. We will end up maintaining them ourselves like the BSDs.
So whenever I see someone requesting Chromium support for Haiku, they are going to wait in years. Not sure about the attitude of the Firefox maintainers but a port + upstream is still years away. For now, we are better off with supporting WebKit.
Yes it does and its used by Linux and BSD targets. gecko-dev/widget at master Ā· mozilla/gecko-dev Ā· GitHub
The GTK Haiku port itself uses the Broadway backend (HTML5) and is still experimental anyway and isnāt enough. One benefit for porting GTK is that you get some of the implementation of the widgets + other apps that use it for free including Firefox.
Thatās if one doesnāt want to write a specific Haiku toolkit for every project that has win, cocoa, gtk backends.
Is it possible to build Firefox/Chromium with this port or some other dependencies are still not available on Haiku?
Firefox has been using less and less native GTK widgets thoughā¦ Servo even has Graphene which is probably what theyāll target fully in the future. GTK is mainly used because of flatpak support these days I think, GTK basically handles the portal to display the browser in and provides access to graphics context for the browser engine to render to.
Also
Well, Iām still not sure itās a benefit. Haiku is not meant to be a worse way to run existing Linux apps 
We will stay a second-class OS if we do only that. Focus should be on native apps using the OS to its full power, not ported apps using the same smallest common denominator of OS features they already use elsewhere.
3 Likes
That is why Haiku is labeled as beta software. Use at your own risk. Bugs and security flaws are to be expected. Speaking of which, this is likely part of the reason Haiku is slated to be in beta for a long time still.
There is a patch by @KapiX for QtWebEngine with which it builds but doesnāt render anything. Maybe you can look into that?
UPD: forgot an actual link https://gist.github.com/KapiX/8502596ef66813195cf8d2bec7393cd7
1 Like
extensions beside adblockers for me would be GreaseMonkey and Stylus. Both allow me to patch websites in a way i accept
There are many widely used āLinux appsā that are using Qt and they seem to be very beneficial to some Haiku users. Yes, we should be promoting our own native apps but we also need to attract new developers to write apps using the Haiku API and new users from other platforms.
No disrespect to anyoneās porting work here but how did we get LibreOffice on Haiku again? It was one of the most requested software for Haiku and there were two routes to achieve that: Either port it using the Haiku API or using its upcoming Qt port. Great progress was made on the former but the end result was to use the latter instead. We were very lucky to even have a Qt port as an open-source OS project to give us many cross-platform apps and it is still actively maintained. I also recognise that itās not up to the core Haiku devs to maintain such ports and it should be a community member with the devs upstream to maintain them.
Sure we donāt necessarily need to port GTK to get Firefox or Chromium or any other app that has win, cocoa, gtk backends. We could write a native Haiku API backend for it instead and it will have a quality native Haiku GUI but that route is a lot of work just for a single app which we will end up maintaining ourselves. While a GTK port is equally a lot of work, it will allow more apps on Haiku with the compromise on quality which will always be second-class apps but they can be modified to fit in with the Haiku UI just like the Qt port to satisfy the users coming from other platforms.
While your argument favours quality over quantity when it comes to apps on Haiku, we can still have native and ported apps that can have both since we have complete control over the Haiku APIs and GUI layers. Its just that speaking as an active contributor to HaikuPorts, general users would pretty much care if an app exists and complain about the quality later.
2 Likes
Firefox uses GTK on all platforms as far as I knowā¦ but as I said it is basically just to get a graphics context for Firefox itself to render itās own UI and maybe some dialogs.
But Windows and macOS have their own implementations defined in gecko-dev/widget at master Ā· mozilla/gecko-dev Ā· GitHub and in there GTK is used for Linux and BSD targets which still is a hard requirement for those platforms, regardless of how Firefox is using those widgets. Yes, those UI backends are used to display the contents of the browser, but if one wants to port Firefox, you must choose a UI backend to use.
Like I said, we could use our own haiku UI implementation to solve this or port and use the GTK implementation, both could take years. That is just the first barrier for this and thats even before thinking about graphics rendering and hardware acceleration.
Hmm that may be true. I am pretty sure you also need to get skia working on Haiku to do the actual rendering AFAIK skia does not work at the moment.
At least on Android, it seems possible to use Gecko independently of FF itself using GeckoView:
Havenāt heard anything about something similar for desktop, though. But it does show that modern Gecko can indeed be separated from Firefox itself.
However @KapiXās unfinished Chromium patch does put Blink closer to being ported than Gecko will be and by proxy Chromium, QtWebEngine, and CEF. All this would also likely let us update the already existing Qt web browsers to more recent versions, such as Falkon (formerly QupZilla) and Otter Browser. It would additionally make an Electron port possible which would allow a whole host of web-based desktop apps to be on Haiku, but Iād rather we not discuss that further 
.
LO will start using Skia as the default rendering library in later versions anyways, so getting that to work will eventually have to be prioritized. While at the moment Skia can be disabled in LO, itās not far-fetched to say that it will at some point in the near future become a hard requirement.
Probably true.