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)
I have a roadmap (not written anywhere yet) to make this port success and to be sustainable. Key is to upstream our changes (again) into Mozilla main development.
Up and running with small changes as much as we can
This is important for two reason
smaller changes may be easier to upstream
smaller changes make rebasing easier
I’m working on this targeting Firefox ESR(extended support release) 102 branch because
it doesn’t require dependencies up-to-date
it is is currently supported
it’s not moving target.
Upgrade dependencies to newer
for next step
Rebase porting effort to Firefox main branch
Make existing tests PASS (or mark them as known to FAIL)
Start send patches to upstream from trivial changes
Once we have test coverage, it’s much easier to import upstream changes (new Firefox version feature), to know build bustage, to investigate what change broke our build.
Once fully upstreamed, they(Mozilla) at least consider conflicting code. This also helps us to import upstream changes much more.
We will keep fork repo/branch after the upstreaming done, there is the place we have Haiku-specific relative large implementation that improves UX more. Upstream them one by one if its reasonable.
This is a good roadmap. I’d suggest also writing a “How to compile Firefox for Haiku” post or doc, this makes it easier for others to start contributing.
I have another (yet private) github repo tracking this project and it has my struggling record (almost personal notes). There are some to share for people to look closely or attempt hacking this.
Now I have gecko-dev fork github repo that I shared in this topic. Issues related the code should be convenient in that repo, so I will move some informative open Issues there in coming days.
Would it be possible to build just Gecko and not all of Firefox, initially? Gecko isn’t as conducive to embedding compared to WebKit and Bink, however Jolla Browser (Sailfish OS) and KaiOS have managed to do this. Perhaps it may be possible to create a Gecko-based web browser directly using the BeAPI?