Sending “Haiku” in the user agent string will also allow web sites that try to offer a correctly-targeted download button (as the Firefox site does) to offer a Haiku-specific download button; this is not currently a big deal, but it would be great if the Firefox site could do that for Haiku.
So, correct identification of the OS should be the default position.
Firefox has an Extended Support Release that could be used instead of the regular one to reduce the effort of regular porting.
Btw I am also of the opinion that including “haiku” in the ua would make sense and be cool. Imo when it comes to privacy, the ua is more vague than the public ip and requests sent to the dns resolver and cdn, so there is not much anonymity gained in sacrificing this feature in particular.
Firefox ESR is already available in HaikuDepot as Iceweasel ESR. The only difference is the latter has telemetry turned off by default and the branding.
In practice, maintaining a rapidly evolving project is easier by sequentially porting a patch from one version to the next rather than waiting for the annual release of ESR versions. This is because changes between consecutive versions require minimal adjustments to the patch, whereas upgrading from one ESR version to the next entails far more complex changes and requires resolving code conflicts when applying the patch.
Now that I’ve been using it for a week-ish, I can say that the new native-code Firefox port is waaaaay more stable than the LibreWolf port is.
LibreWolf can only be left running for around 24 hours on my laptop before it starts using so much CPU that it has to be restarted (if it doesn’t just crash out); the native Firefox port is just ticking along normally at 48 hours uptime. Which is about as long as I ever go without updating and rebooting, so that’s awesome.
And not having the mouse leaving visual artifacts all over the browser display is a massive bonus all by itself.
This is probably the biggest single usability improvement since I moved my daily use to Haiku almost a year ago.
Thanks for this. If you get these patches into the LibreWolf port, I’ll probably never touch Firefox again but for now I’ve switched to this port for almost all my browser use.
In my experience, with librewolf and the other firefox based ports, it wasnt CPU that it eventually consumed but system memory, even left sitting idle the browser would gradually consume more and more RAM, more rapidly if being used heavily, until all available RAM was consumed, at which point it becomes virtually impossible to end the team(s) or even shutdown the system normally. looks like some sort of memory leak.
Even closing the browser wouldn’t totally release all RAM and repeated cycles of using the browser until nearly all the RAM was consumed and closing it would yield diminishing returns until you just had to restart the whole system.
However, the last big update that was issued seems to have significantly reduced the severity of this observation. still waiting to see if it’s totally mitigated or not.
The LibreWolf port is definitely leaking lots and lots of RAM too, but the CPU monitor would show 1 core as being completely maxed well before memory exhaustion hit and the entire GUI would lag massively as long as that core stayed maxed. So I, at least, was hitting a CPU bottleneck before a memory one.
The CPU would go back to normal on restarting the app, but not the memory so my experience lines up with yours on that.
Last time I poked at the memory usage growth, it was mostly in page tables in app_server from Gecko creating and destroying a separate buffer for every single frame rendered. Killing app_server to restart it frees that memory, but the new port properly reuses buffers and so doesn’t have this problem.
i figured it was something to do with paging or caching, since the bulk of the RAM usage didn’t show in the browser teams themselves. but indeed the latest build does seem to have resolved it, i have had the browser open doing things now for at least a few days without needing to purge it and restart everything.
I just set that to false (on Win10)… Holy cow! Thank you! Makes trying out vertical tabs far less annoying! (I want vertical tabs on the right, but the weird color changes made it too distracting).
Speaking of Nova,I really don’t understand why they make a big complete redesign like every year or so,only to make everything worse each time.
There’s luckily a community project that brings back older designs:
It’s always among the first things I install when setting up LibreWolf anywhere.
Also works on Haiku,but the installer script currently doesn’t find the profile directory,so manual work is required.
Now I’d only need the same thing for the mobile version,where the last redesign ruined everything with no way back
Big news for the LibreWolf fans
The current package (version 157.0-1) comes with the same massive improvements Firefox recently received.
No cursor flickering anymore,much improved performance with less CPU and RAM usage and all.
Just found that out accidentally when testing if Firefox-UI-Fix (see last post) still works on the latest version.
It looks like a fix was added too that when restarting Haiku, Haiku closes it properly. Used to get a warning “… Firefox is preventing a shutdown/reboot”.
I wonder what you mean by performance here? I did try it after your message but scrolling was a bit slow, I turned off smooth scrolling which did help, but not by much
Scrolling works perfectly fine for me,with smooth scrolling enabled.
Also,animations on websites are running fluently without flickering or delays.
Can’t notice any difference compared to LibreWolf on OpenIndiana or Windows at this point.