OMG, about:processes is not working…
The new Firefox build works surprisingly well 
What still causes issues,however,is showing menus like context menus or the application menu or extension popups.
Most menus work when opening,then closing,then opening them again.
Only for extension popups that doesn’t work,I never get them to open.
And uBlock Origin takes rather long to initialize after opening the application (1-2 minutes),during that time all network requests are caught in a loading state.
It’s still an amazing progress and I’m sure the remaining issues will also be solved at some point.
3 Likes
On my side, the only way to access to a website is to give the URL after the call to the firefox executable.
Else I have the below on my computer :
- The refresh of the screen is only done when I’m moving another window on top of Firefox
- The mouse click or keyboard is not recognized for an unknow reason, that’s why I’m stuck here :
The screen not refreshing most likely means that you didn’t install the patched wayland_server package.
@KENZ already shared it above,but here is it again for convenience: https://oshi.at/eQMc
You need to download and install it,replacing your existing wayland_server with it.
Then the screen will properly refresh.
4 Likes
Ok I have uninstall and reinstall wayland_server with the package provided + install again the lib dependency and it’s working fine now !
Posted from Firefox 
1 Like
how did you fix the libxul error?
I installed the packages given above but get this:
XPCOMGlueLoad error for file /boot/home/Downloads/firefox/libxul.so:
Missing library
Couldn't load XPCOM.
See here Progress on porting Firefox - #207 by michel
Also you can find which lib is really missing by running cat /var/log/syslog
2 Likes
yep sorry got it in the meantime because I was looking up some other error in the syslog
KERN: runtime_loader: Cannot open file libevent-2.1.so.7 (needed by /boot/home/Downloads/firefox/libxul.so): No such file or directory
So the libevent package was missing from the list.
Also, you have to set the DISPLAY variable, e.g. for local display, as commonly used, it’s
export DISPLAY=:0
It’s blazing fast, really nice work!
2 Likes
Project lacks manpower, if you want to join fixing things, I can coordinate LibreWolf tree to build.
Though I will be stick with upstream (mozilla’s repo) as it should be easier to submit patches. But I can understand you want to keep distance from any telemetry or other privacy risked assessment features.
If you fixed some issues and taking them should pay off.
1 Like
Really? It is X11 display setting, but this Firefox port use Wayland, so DISPLAY variable should be not relevant.
1 Like
Unfortunately, I didn’t write down exactly what pkg fixed the libxul error. I am going to do another fresh install and make a note of packages that I install to get running.
Edit: I just saw that you found it was the libevent packages
3 Likes
True but Firefox complained and would not start otherwise…
You need to set WAYLAND_DISPLAY=:0 instead of DISPLAY env as I noted in
but it may also lookup DISPLAY env.
1 Like
Oh thanks I’ve missed that last part and yes, it’s seems to fall back to the legacy var in my case.
I don’t think I can help a lot at this point.
As long as it gave compiler errors,I could have a look what it complains about and fix this.
Now that it’s running but misbehaving,I have no real idea where in this extremely huge codebase I should look.
About the menus and popups not showing,I think it could probably be another bug in wayland_server and not directly in Firefox,but honestly I don’t know.
Also,building the code didn’t succeed on three different setups,which lead me to give up.
- On my huge powerful server,running from an USB stick because Haiku doesn’t have drivers for the RAID controller,disk I/O is extremely slow and the unpacking of the LibreWolf source archive alone took several hours.
- On my huge powerful server,running OpenIndiana from the SSD and Haiku in a hardware-virtualized QEMU VM with the disk image stored on the SSD,Haikus disk I/O is again very slow.I think it took less hours here,but still way too long.And sometimes Haiku within the VM would just freeze.
- On my new laptop that I only bought a few weeks ago especially for huge compile workloads on Haiku,unpacking the source archive works fine,so does applying the patchset with your Haiku-specific changes.Building starts,you can hear the fans getting loud and then at some early step,nothing.It’s just stuck there forever,CPU load goes down to zero and nothing happens,no error is shown also.I think that was still in the configure part or shortly after.
2 Likes
Thank you for sharing your fight with building the monster. Indeed large amount of files is troublesome on Haiku (especially on thunb drive). I avoid myself cloning all history from the git repo.
I don’t start trying to package this as I cannot publish this isn’t usable at all before the wayland_server package updated.
As I’m new to packaging into .hpkg, when it is ready I hope someone rend me their hand. Then the large tarball can be problem.
Maybe you can use: HPKG Creator - BeSly Haiku only
You can zip it up (or tar.gz/tar.bz2/tar.xz) and we can help package it for you (or anyone from the HaikuPorts team).
1 Like
You can probably start with updating this old BeZilla recipe here
2 Likes
If you have lots of memory you can use ramfs for that. I know that it was used to build openjdk many years ago.
I tried that and it gave errors.
Certain types of files aren’t supported in the ramfs,but I can’t remember what it was that caused issues in the Librewolf source.
Also from porting Ladybird I know that putting socket files on a ramfs doesn’t work,but I don’t think Librewolf compiled as far as to create any socket files.