Firefox and Librewolf

[Grogan]

Firefox 123.0 is out today, but with no release notes yet.

https://ftp.mozilla.org/pub/firefox/releases/123.0/

I wouldn't expect it so soon, but I did check Librewolf and there's nothing yet. They DID eventually release a 122.0.1 but by that time it was a day late and a dollar short, there was no point in me doing it for nothing that likely would ever have affected me anyway. I'll do 123 though.

I'm going to be doing both from now on, so I'll post news about them in the same threads.

[Grogan]

I was unsuccessful at building Firefox 123.0 with LLVM 17 and Rust 1.76.0 (just upgraded that today before the firefox build). The first phase of the build completed and ran for profiling, but it bombed out during the LTO build near the end. It looks like the compiler (clang++) crashed which can happen with LTO failures (it's not the first time I've seen it happen in that circumstance).

There's some tomfoolery with mismatched target triples (I forgot to patch Rust to use x86_64-pc-linux-gnu instead of unknown) but that shouldn't have caused any problems (just floods of warnings).

I'll have to try again overnight, I'll first put back my old Rust 1.75.

P.S. I decided I should rebuild LLVM. Shouldn't be necessary, but the system has changed since. I'll get the latest fixes for the 17 branch. LLVM 18 isn't a release yet, they switched convention, it won't be "stable" until 18.1.0 so I'll hold off on that. Then Rust 1.76 built properly again etc. and we'll try firefox again.

Nope... I awoke to the same crash. Actually it's the linker, lld, segfaulting during linking of libxul but it's clang++ throwing the error on invocation. I guess I'll have to try older Rust. It doesn't look like Rust is the problem but weird stuff can happen with LTO during linking that monstrous libxul and Rust 1.76 is what's new here.

[Grogan]

Firefox 123.0 Release Notes now:
https://www.mozilla.org/en-US/firefox/1 ... easenotes/

We’ve integrated search into Firefox View. You can now search through all of the tabs on each of the section subpages - Recent Browsing, Open Tabs, Recently Closed Tabs, Tabs from other devices, or History.

Having any issues with a website on Firefox, yet the site seems to be working as expected on another browser? You can now let us know via the Web Compatibility Reporting Tool! By filing a web compatibility issue, you’re directly helping us detect, target, and fix the most impacted sites to make your browsing experience on Firefox smoother.

Fixed

When translating web pages, we are now also translating text in tooltips (i.e. titles) and text displayed in form controls (i.e. placeholder).

Various security fixes.
https://www.mozilla.org/en-US/security/ ... sa2024-05/

Changed

Address bar settings can now be found in the Firefox Settings' Search section.

Improved PGO optimizations for macOS ARM64 and Android

Off-main-thread canvas on macOS, Linux and Android

[Grogan]

Well, bummer... I knew it had to do with vector instructions from the backtrace, but I was thinking it was more the rust SIMD in the new Rust. It had nothing to do with Rust at all. I tried with my previous Rust 1.75.0 (didn't need a rebuild for LLVM... it's static) and had the linker failure (a process segfaults). So it had to be something changed in the Firefox 123.0 build that's causing my LLD linker to barf during LTO linking of libxul.

I first tried changing my -march=nehalem to -mtune=nehalem (C/CXXFLAGS for Clang) and that solved it. That wouldn't use anything more than SSE2 with -mtune on x86_64.

I didn't change my RUSTFLAGS at all, it's still "-C target-cpu=nehalem -C debuginfo=0".

I've been building Firefox with -march=nehalem since forever (my whole system is compiled like that). I hope that stops happening soon (maybe lld won't barf in LLVM 18, or whatever offending code changes etc.)

[Grogan]

I decided to try my luck with LLVM 18.1.0-rc3 since it's almost ready. What the hell, there's a reason I dropped all shared dependencies on its libraries. It's disabled for mesa... I use ACO only and even Rust now I link to it statically. At least I can get a new Rust build (bootstrap) off the ground with it that way. So I don't break anything and if I have to roll back I don't have to recompile anything. When you think about it, that's a lot less fragile than gcc, which has critical shared libraries like libgcc_s and libstdc++ and may need a recompile if you change API headers and glibc.

The only thing is I won't be able to build Firefox with the WASI sandboxed libraries, as the wasi-sdk is still at LLVM 17 code base (assuming Firefox compiles at all). So sad.

Good luck to me

P.S. Fuuucckk... the whole build completed (almost) in 120 minutes (7500+ objects) without one single warning (I compile it with clang), but I didn't know about a new default. libcxxabi now has LLVM unwinder (libunwind) support turned on, but I don't compile libunwind. I don't do debugging, I don't care.. I don't even really need LLVM's libcxx/libcxxabi (I don't link anything against it, I use gnu libstdc++), I just enable it... because. So, as soon as it started the cmake configure for the cxx runtimes (separate now), it barfed because of the libunwind configuration. I have to add libunwind to the runtimes and start the build over lol

Code: Select all

-DLLVM_ENABLE_PROJECTS="compiler-rt;openmp;polly;clang;clang-tools-extra;lld"
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind"

I'm glad I started early, I'll still at least get this done before game time.

[Grogan]

Yeah, some of these LLVM based tools actually crash when they hit some conditions. After upgrading my LLVM to 18.1.0-rc3 I first tried to compile the current stable Rust 1.76.0 and it failed so horribly that rustc segfaulted. It got most of the way through, built the rustc compiler and std library, but failed on cargo during this "memchr" crate. Now, in both of these cases (lld/clang LTO barfing on instructions for me during firefox build and Rust trying to use a not yet compatible LLVM interface) those were absolute nopes anyway, so it doesn't matter that they crashed as a symptom lol

Anyway, I had to grab a nightly source snapshot tarball of Rust, "1.78-nightly". It has the changes I need (committed a week or so ago). It was quicker than git cloning and checkout etc. and only has the needed sources (not the whole repo with bundled llvm etc.) I have a working rust install, with my LLVM 18 built in. As to whether it's of use to me or not (being able to build Firefox is hard requirement) I'll have to see later.

I guess I got in deeper than I had thought, my chances of success are smaller now. Ficklefox and all. I like screwing around with this stuff though, and it's a head start on things I'm going to have to get worked out anyway.

[Grogan]

So that Rust 1.78-nightly wasn't any good for building Firefox. Too many of their crates are not compatible.

However, that doesn't really matter at this time because I have a perfectly good Rust 1.76.0 with LLVM 17.0.6 built in that I just put back. The benefit of static linking.

LLVM 18.1.0 itself is fine, I don't have to roll that back. I got a good plain (non-PGO/LTO) build with that and my Rust 1.76, with -O2 -march=nehalem. Tomorrow I'll try a full PGO/LTO build now that I know this is viable.

[Grogan]

It looks like my problems with LLVM 18.1.0 and Firefox go deeper. My plain build last night was fine, but when compiled with profiling hooks, the browser won't run for profiling. I'm doing a manual build (stepping through the commands rather than script and I'll try profiling in my X11 session instead of xvfb) so I can get a better idea of what happened. With my script, as soon as the profiling exited (firefox died with signal 11, which is segfault) my script proceeded to clobber and run mach with the profile-use mozconfig, which aborted because there was no profile data. So there was no build left to try to run manually lol

I'm probably going to stick with non PGO builds until things catch up. My current build with -O3 globally only has minor performance regressions vs. my usual PGO+LTO. (wouldn't notice them in the real world). Or I could compile the browsers on Arch for now. I have LLVM 17.0.6 there with a recently built Rust 1.76.0.

P.S. Adding the LLVM 18 instrumentation code for profiling must be corrupting the program. With profile generate enabled, the results just won't run (insta-segfault) even in the right context. That was a conservative build too, no -march or RUSTFLAGS.

[Grogan]

I set up a build in Arch before bed last night (my way, not PKGBUILD). LLVM 17.0.6, Rust 1.76.0 with my WASI stuff dropped in. I used -mtune=nehalem because the LLD linker will crash on libxul with LTO. That's still better than a flat build with -march (benchmark scores).

Arch skipped LLVM 16 altogether, they are still at 16.0.6. Bollocks.

Anyway, reading some bug report threads it looks like LLD crashing is a thing, on some failures. I saw someone reply that it's still a thing as late as Jan 16. LLVM particularly doesn't like it when you mix different LLVM IR's. (intermediate representation between source and machine ASM) which makes sense in context of my rustc failure. It's not graceful, but these are show stopper build errors anyway.

[Grogan]

So Librewolf 123.0-1 has been released

https://codeberg.org/librewolf/source/r ... ag/123.0-1

I'm going to have to build this on Arch for now (I don't want to downgrade my LLVM, for when 18.1.0 is a release it'll be easier to upgrade (blast DESTDIR through /usr instead of having to manually delete). I'd expect it in a week or so (March 5'ish).

[Grogan]

Firefox 123.0.1
https://www.mozilla.org/en-US/firefox/1 ... easenotes/

Fixed the Firefox Translation language indicator in the address bar displaying a colored square icon instead of the language code icon. (Bug 1879415)

Fixed incorrect rendering of Canvas2D conic gradients colors on Windows. (Bug 1851963)

Fixed a regression with the onChange event not firing when clearing the value of a textarea HTML field. (Bug 1881457)

Fixed availability of system-level dictionaries for Linux users with Firefox installed as a Flatpak package. (Bug 1881830)

Fixed a regression in the JavaScript JIT engine incorrectly inlining strings in some cases. (Bug 1882386)

Fixed low contrast of text when selecting rows in the Developer tools' Storage panel. (Bug 1877090)

I guess I'll start that before bed. This will be the last Firefox build on this computer (and it'll actually be coming along with the NVME drive so I'll have it immediately on the new one until I get all my dev shit set up and build directories copied over)

[Grogan]

I tried a build of firefox with -march=alderlake (and "-C target-cpu=alderlake" for rust). It was the same deal as with nehalem for the firefox 123 cycle, the first stage compiled and profiled and the second stage got almost to the end and the linker segfaulted on the failure, during LTO linking of libxul. I might try something like "-march=nocona -mtune=alderlake" to eliminate some of the later SSE instructions like 4.2 to see if that's it. I don't mind experimenting now, because it takes about 30 minutes to find out, vs. 160 to get to that point on the old box. Profiling still takes about 10 minutes.

In the mean time I did a plain build (non LTO) and it's good. So it's likely to be OK to use alderlake for most things if firefox survived it. A plain build of firefox takes me about 10 minutes (with MOZ_PARALLEL_BUILD=24)

I have to establish new baselines for benchmarks to say "how good" though and one of the tests I use, Browserbench's Speedometer, has changed drastically in version 3.0, with completely different scoring so I can't even compare that one to the old box.

[Grogan]

I got a successful PGO+LTO build of Firefox with -march=core2 -mtune=alderlake. (that's one better than nocona and one below nehalem which has SSE4.2 and popcnt). The -march=core2 can do everything nehalem does except SSE4.2/popcnt.

Code: Select all

 export CFLAGS="-march=core2 -mtune=alderlake"
 export CXXFLAGS="-march=core2 -mtune=alderlake"
 export RUSTFLAGS="-C target-cpu=alderlake -C debuginfo=0"

It took 32m 14s for the whole build, profiling and all.

So I can likely conclude that SSE4.2 instructions were what was causing the linker failure.

Now an interesting test is going to be comparing benchmark scores between last night's plain -march=alderlake build and this one. I expect the PGO+LTO optimization is going to be more significant than building the whole thing with -march=alderlake. I did 3 trials of my tests and recorded them last night for this very purpose.

[Grogan]

Well, the data is in. As expected (and previously observed on the old box), the profiled build is significantly better than the non-profiled build. If a PGO+LTO build can't succeed with a particular -march=cputype, adjust the -march rather than dropping the PGO+LTO build method.

Rust isn't having a problem with the target-cpu type, so that's the same between both builds.

Speedometer 3.0 is a completely different test now and can't be compared in any way to Speedometer 2.0 scores (they are scored differently, lower values)

Code: Select all

Firefox 123.0.1 (plain build -march=alderlake -C target-cpu=alderlake for rust)

Speedometer 3.0

20.9
21.1
20.7

Jetstream 2.1

228.999
226.033
225.740

MotionMark @60fps

1807.51
1783.89
1782.37

Basemark Web 3.0 (bouncing ball canvas test still doesn't render correctly... doesn't seem to affect test score)

2147.9

The profiled core2 alderlake tuned build scores significantly better in all tests. EXCEPT the Basemark Web 3.0 has some bollocks tests at this time. I only ran that one once last night because it pissed me off. First of all, a network test that skips iterations when there is too much latency. It doesn't skip the whole test, just iterations so no two scores can be compared. That's about as scientific as the flat earth society. Secondly, starting with Firefox 123.0, there's a canvas test that doesn't render correctly. The balls don't move fluidly and bounce around, they just jerk around. Yet it goes ahead and calculates a high score for it just the same.

Code: Select all

Firefox 123.0.1 (PGO+LTO -march=core2 -mtune=alderlake -C target-cpu=alderlake for rust)

Speedometer 3.0
26.6
26.87
26.61

Jetstream 2.1
238.408
239.415
238.715

MotionMark @60fps
2033.24
2067.17
2039.73

Basemark Web 3.0
1982.99
2650.68
2761.7

[Grogan]

Firefox 124.0 is out now, with release notes even. Good timing for me

https://www.mozilla.org/en-US/firefox/1 ... easenotes/

They aren't listing much, in the way of user facing changes.

Caret browsing mode now also works in the PDF viewer. (Learn more)

In Firefox View, open tabs can now be sorted by either recent activity or tab order. Recent activity is the default setting.

Firefox now populates the Windows taskbar jump list more efficiently, which should allow for a smoother overall browsing experience.

Firefox on Mac now uses the macOS fullscreen API for all types of fullscreen windows. This should better match the expected macOS user experience for fullscreen spaces, menubar and the Dock.

As of Firefox 124, Qwant's availability has been expanded to all languages in the France region along with Belgium, Italy, Netherlands, Spain, and Switzerland.

Fixed

Various security fixes.

[Grogan]

AVX sure is deadly poison

I thought I ought to be able to run my Firefox build over on the other box, "-march=core2 -mtune=alderlake" but that's just for C/C++. I forgot that I didn't need to disable target-cpu=alderlake for Rust. So it just instantly barfs with illegal instruction over there.

But... since it only takes half an hour on this box, I'm going to build a nehalem one for the other box.

This is the kind of shit I have fun with, not screws and connections.

[Grogan]

Firefox 124.0.1 now
https://www.mozilla.org/en-US/firefox/1 ... easenotes/

It's all security fixes
https://www.mozilla.org/en-US/security/ ... sa2024-15/

[Grogan]

OK now... Firefox 124.0.1 builds and profiles with LLVM 18.1.2 now (and Rust 1.77 builds with LLVM 18.1). Firefox still can't PGO+LTO build with SSE4.2 though (linker barfs on final libxul) which means it can use "-march=core2 -mtune=whatever" at best.

I haven't done that WASI shit yet, but looking at the github project the LLVM version has been bumped to 18.1.0 so that will be viable now too (after I get patches in order to remove bulk mem operations)

So... my Arch is going to be getting a LLVM 18.1.x upgrade soon too.

[Grogan]

I upgraded Arch to LLVM 18.1.2 (and rebuilt Rust against it) yesterday. Due to my recent revelation that static runtime code is significant, I'm now building those things a second time with each other.

Arch takes too long with LLVM upgrades, they've only recently upgraded to LLVM 17 a few weeks ago. I tend to see minor performance improvements with LLVM machinery upgrades and now that Firefox is up to speed, I want that.

Small, but reproducible gains. This isn't caused by firefox 123 -> 124, it's the toolchains. I did a few quick tests with 124 the other day and didn't see change significant enough to record.

Both of these are using the "WASI" sandboxing, but I don't think that affects performance (at least not that you'd notice, or see in benchmarks) for it's only a few bundled libraries that compile like that.

Code: Select all

-----------------------------------------------------------------------------------------------------------------------------------------------

Firefox 123.0.1 (LLVM 17.0.6 Rust 1.76.0 PGO+LTO -march=core2 -mtune=alderlake -C target-cpu=alderlake for rust)

Speedometer 3.0
26.6
26.87
26.61

Jetstream 2.1
238.408
239.415
238.715

MotionMark @60fps
2033.24
2067.17
2039.73

Basemark Web 3.0
1982.99
2650.68
2761.7

-----------------------------------------------------------------------------------------------

Firefox 124.0.1 (LLVM 18.1.2 Rust 1.77.0 PGO+LTO -march=core2 -mtune=alderlake -C target-cpu=alderlake for rust)

Speedometer 3.0
27.2
27.2
26.8
27.2

Jetstream 2.1
241.725
239.918
243.059


MotionMark @60fps
2145.94
2152.92
2145.74

Basemark Web 3.0
2389.36
1908.42
2153.26

---------------------------------------------------------------------------------------------------

That Speedometer 3.0 test is so reproducible I almost didn't trust the test. I kept getting scores of "27.2". That's a round-off (e.g. 27.202215122132532... or something) but still. If I didn't see that 26.8 score I'd have said bollocks.

Now, Basemark Web 3.0 still gives bullshit final scores because of the network responsiveness test (that's just silly... should use local data for page loading responsiveness tests, or it's just never going to be reproducible)

However, with THIS build (not the previous day's with the old toolchain) the bouncing ball canvas test works correctly. It starts out really fast and then starts to slow down when the bouncy ball patterns get more complex now.

Another thing that makes Basemark a poor test, is that they change how the tests work and never bump the benchmark version. It's been "3.0" for several years.

[Grogan]

We seem to have a Firefox 124.0.2, but no release notes
https://ftp.mozilla.org/pub/firefox/releases/124.0.2/

Maybe it's related to embedded liblzma compression in some codec or something.

P.S. Got mine done in half an hour, while I was upstairs snacking and stuff. It doesn't even interfere with gaming anymore

[Grogan]

https://www.mozilla.org/en-US/firefox/1 ... easenotes/

Fixed an issue where users with a large amount of bookmarks would be unable to restore a bookmarks backup. (Bug 1884308)

Fixed an issue that would cause open Firefox windows to go blank or crash during video playback on sites such as Netflix. (Bug 1883932)

Fixed a crash that affected Linux AArch64 builds.(Bug 1866396)

Fixed an issue where some users experienced difficulties loading webpages due to changes made to the default AppArmor configuration shipping in Ubuntu 24.04. (Bug 1884347)

Nope, not related to the xz issue in any way. I looked through the source dirs and didn't see any liblzma but thought maybe something might have that decompressor built in.

[Grogan]

Hey, it looks like we've got Firefox 125 now but no release notes as usual.

https://ftp.mozilla.org/pub/firefox/releases/125.0.1/

Interestingly, it seems they skipped or removed 125.0, it's not in the repository at all. They must have seriously messed something up.

I'll get this built then we'll see if there is anything new to annoy me

[Grogan]

Firefox 125.0.1 Release notes (for 125... they skipped 125.0)
https://www.mozilla.org/en-US/firefox/1 ... easenotes/

Firefox now supports the AV1 codec for Encrypted Media Extensions (EME), enabling higher-quality playback from video streaming providers.

The Firefox PDF viewer now supports text highlighting.

Firefox View now displays pinned tabs in the Open tabs section. Tab indicators have also been added to Open tabs, so users can do things like see which tabs are playing media and quickly mute or unmute across windows. Indicators were also added for bookmarks, tabs with notifications, and more!

Firefox now prompts users in the US and Canada to save their addresses upon submitting an address form, allowing Firefox to autofill stored address information in the future.

Firefox now more proactively blocks downloads from URLs that are considered to be potentially untrustworthy.

The URL Paste Suggestion feature provides a convenient way for users to quickly visit URLs copied to the clipboard in the address bar of Firefox. When the clipboard contains a URL and the URL bar is focused, an autocomplete result appears automatically. Activating the clipboard suggestion will navigate the user to the URL with 1 click.

Users of tab-specific Container add-ons can now search in the Address Bar for tabs that are open in different containers. Special thanks to volunteer contributor atararx for kicking off the work on this feature!

Firefox now provides an option to enable Web Proxy Auto-Discovery (WPAD) while configured to use system proxy settings.

Various Security Fixes

In a group of radio buttons where no option is selected, the tab key now only reaches the first option rather than cycling through all available options. The arrow keys navigate between options as they do when there is a selected option. This makes keyboard navigation more efficient and consistent.

More for Developers and the web platform (see link above}

[Grogan]

Not that skipping a release meant they got everything right the first time, no, it's Firefox 125.0.2 already. Fucking online automated updates are a scourge, because nobody gives a shit about bugs before release anymore.

https://www.mozilla.org/en-US/firefox/1 ... easenotes/

Reverted the changes recently shipped in Firefox 125 that more proactively blocked downloads from potentially untrustworthy URLs. The changes caused unexpected problems with downloading files in some situations. We plan to fix and re-enable these protections in a future release. (Bug 1892069)

I guess I have no need to build this one, as there are no changes that will affect me. I have all that "Deceptive Content and Dangerous Software" blocking shit disabled. I decide what I'm going to download, not nanny software.