I am a big fan of Firefox and a long-time watcher of Haiku (and BeOS).
I love Haiku’s cute UX (inherited and polished from BeOS), so WebPositive looks sweet, but I dreamed also firefox will be available on Haiku in the future.
Recently, Haiku gets the Wayland compatibility layer, it runs gtk3, gtkwebkit and GNOME Web(epiphany) with relatively small additional porting effort, this convinced me it is viable to port Firefox on Haiku now.
I spent some weekends and managed to build firefox binary (with a few stubbing platform specific code to be written later).
It spawns main child process, creates initial (Firefox) profile directory, and opens Wayland display, but then it crashes.
If my knowledge is correct, to get an (E)GL context on Haiku, a BGLView is needed, a BGLView should be added to a BWindow before retriving the context.
Wayland compatible layer has underlying BWindow in it, so to get the EGL context from it, wayland-server implementation needs change.
X512 is already working on it, so I’ll wait it will be available.
I think the EGL situation is much improved, on Haiku as a whole at least, with the new Mesa version plus libglvnd. I don’t know what changes are needed in the Wayland compatibility layer beyond this, however. That isn’t ready just yet, it’s waiting on a new Mesa release. There is a HaikuPorts ticket which describes how to test it, though.
The HaikuPorts developers can almost certainly upgrade this without too much trouble. Any other packages that need manual installs which could be fixed there?
Thank you for sharing latest status on Mesa. I’m working on Haiku R1b4 because it stable and new enough to work with wayland compatibility, but new Mesa update requires nightly?
Thanks to nielx, he maintains relatively new Rust toolchains, cbindgen is now 0.20 on haikuports, but firefox build requires 0.24 (0.20 version actually failed generating some bindings correctly.)
It seems I need raise my priority on implementing Haiku Wayland EGL support. It need to implement software drawing code using Wayland in Mesa Haiku EGL code. Linux Mesa Wayland support is not usable because it depends on DRI framework and Linux-specific ioctls like fence FDs and implicit sync registration.
Thank you for your interest in my work, and I appreciate to your large contributions on the GUI/3D stack. It is critical on porting Firefox because now Firefox has only GPU-based rendering path(aka WebRender) and software rendering path depends on software renderer like Mesa LLVMpipe or so.
(Of course, I owe to many people work, Haiku’s mature POSIX support, many dependent libraries already ported in haikuports, rust ported and updated, and so on…)
I saw you’re testing Qt with EGL, so I’m optimistic you’ll progress it near future.
Nice! I was one of the developers on the old Firefox port for BeOS/Haiku. I’ll take a look at your project and see if I can give any hints. It probably diverged a lot since then so might not be much use.
Looks like it has changed a lot: nspr: Netscape Portable Runtime, still there, but much simpler now. As we should be able to use pthreads probably no need to do much here. gfx: Not sure if much is needed here for Haiku but we used to to have our own rendering here. widget: Window handling, looks similar to old days, can probably use old bezilla widget code as start when/if wayland is not working. Firefox event loop was a big problem back in the days, perhaps less so now. xpcom: cross platform com, seems to still have some platform specific parts.
@tqh Yes. I know your name in the Bezilla team. Though I couldn’t remember if I gave it a try to use Bezilla in its era.
Thanks to take your time to look into my project, I’m non-native, so sorry for ugly commit comments.
Yes, XPCOM survives glacial epoch but most of its usage is banished for performance, and now it mainly used for xpconnect (C+±JS interoperatibility).
For gfx/widgets, indeed these modules may be Haiku specific implementation, but I think we should rely on X/Wayland surface as much as we can.
As Firefox development team (and community) is now very small (compared to 2000’s and compared to other browsers) they don’t want to maintain many OS/platforms.
Of cource, they should take paches in if community maintains them well, but now Haiku has native rendering engine (HaikuWebKit) and browser, so ported softwares should be maintained with no hassle to be sustainable.
Makes sense. I would probably have all OS components as loadable plugins. Easier to recompile and work with than the whole base, as long as interfaces are well defined.
It would be interesting to drop in the old BeZilla code and see how much has changed, at least. The Wayland layer does add some overhead, and if we can bypass that overhead entirely, that might be the best idea. Plus, it’s not just X/Wayland, but GTK3; a Firefox port that didn’t use GTK would be really the best.
My advice as the main HaikuWebKit maintainer is to start with getting things running using cross-platform code, and once you have it running, you can consider replacing parts with more native solutions. That will be simpler than trying to get everything native from the start, as it allows to test each part separately.
Bezilla code was removed 12-13 years ago, so I doubt we can drop them into current mozilla code base easily. They largely refactored their code from then and recently some part of platform dependent logic moved into third-party libraries.
But yes, indeed wayland layer brings some amount of overhead (especially in memory footprint), GTK prevents us from behaving like native (controversial word in here!). So in longer term, we should consider replacing them.
In short term, I’ll refer Bezilla code after we successfully open Firefox window and basic operation achieved, to fill stubbed code, to re-enable some advanced features that we disabled to build, and to improve Haiku integration.
FYI, You can see this Bugzilla “Attachments:” (click “Diff” links of each attachment) to know the amount of code and what type of logic/implementation in it when the Bezilla code has been dropped from Mozilla codebase:
Largest part was widgets it was 304.16 KB in patch size, it includes:
Display info and windowing (filled by GDK/EGL/wayland compatibility layer)
Windowing code (Create and manage top level window and child window, child (native) view (maybe was for NPAPI plugins which is already dead))
Screen (display, monitor) information
Low level event handling (maybe filled by wayland or GTK/GDK code, threading by POSIX thread)
Event loop (and threading)
Mouse event and keycode mapping
Higher level event handling (filled by GTK code)
D&D support code (complex, as it is actually complex, related to clipboard, event, web-content JavaScript interaction)
Clipboard support
IME integration (this also complex, this part was largely refactored in upstream, by my friend masayuki who is module owner of event handling in Firefox)
BeOS cursor code
System dialog integration (filled by GTK code)
File picker integration
Print setting integration
Audio (maybe some of them filled by GTK code)
Playing sound (maybe caller changed largely)
Now unused
Native widget L&F support (Drawing widgets on web(and fx ui) in BeOS style, but this mechanism was dropped from upstream)
Next in size was xpcom 41.07 KB in patch size, it includes
Basic file loading, and dynamic loading(dlopen-like) mechanism (mainly filled by POSIX support)
OS specific file path handling (currently missing behaves like UNIX, maybe need a fix)
Next in size was toolkit 30.36 KB in patch size, it includes
Application startup abstraction (filled by Haiku’s POSIX support for now)
Next in size was gfx 30.27 KB in patch size, it includes
Font selecting, text rendering (filled by freetype/harfbuzz. web contents require advanced feature from harfbuzz)
Vector drawing library(cairo) integration (maybe filled by skia for basic drawing, cairo for printing, high-performance path(aka Moz2D) uses EGL to tessellate 2D vector path)
