Firefox 146 released

[Posted December 9, 2025 by jzb]

Version 146.0 of the Firefox web browser has been released. One feature of particular interest to Linux users is that Firefox now natively supports fractional scaled displays on Wayland. Firefox Labs has also been made available to all users even if they opt out of telemetry or participating in studies. "This means more experimental features are now available to more people."

This release also adds support for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for WebRTC. ML-KEM is "believed to be secure against attackers with large quantum computers". See the release notes for all changes.

to post comments

Fractional scaling?

Posted Dec 10, 2025 14:08 UTC (Wed) by raven667 (subscriber, #5198) [Link] (6 responses)

I'm not sure I understand what is new/changed about Firefox on fractionally-scaled Wayland displays, I've been using Firefox on a laptop with two displays, one scaled at 125% and one 175% without problems for years, so what is now supported that didn't work before?

Fractional scaling?

Posted Dec 10, 2025 14:21 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

There's two ways to handle nicely fractionally-scaled Wayland displays:

The legacy method that's been present since relatively early days; Firefox renders to an integer scale of your real display (100%, 200% etc), and the compositor upscales/downscales to the final scaling - e.g. you might manage 125% scaling as 100%, and upscale to 125% or as 200% and downscale to 62.5%.
The method added by the fractional-scale-v1 protocol extension, where Firefox renders at the fractional scale.

Up until Firefox 146, the only method possible was the legacy method; Firefox renders as-if it's outputting to an integer scale of your display, and your compositor scales to the final size. With Firefox 146, it now respects the compositor saying "please render at 125%" and the compositor need not scale at all.

Fractional scaling?

Posted Dec 10, 2025 17:19 UTC (Wed) by higuita (guest, #32245) [Link]

and doing this in the application side can better solve some corner cases that the legacy scale can have some problems (example: some text or images are blur or higher performance degradation on more complex images)

Fractional scaling?

Posted Dec 10, 2025 20:05 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Thanks, unlike with older Chromium where you would get a blurry window if you didn't set the native Wayland ozone renderer on the CLI, I've never noticed a quality issue with Firefox rendering, so I guess the built-in compositor-based scaling is pretty good. Looking forward to applying the update.

Fractional scaling?

Posted Dec 11, 2025 9:31 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

The main problem with legacy scaling is that scaling is a destructive operation (it is basically a form of rounding things up), the more so if you downscale then upscale. It is always more accurate to directly scale to the target physical pixel grid. Of course the more pixels you have in the initial scaling the less you lose quality in further rescaling. However massively increasing the initial scaling to mitigate rescaling loses is very taxing on memory and GPU hardware.

Also it has long been recognized that the humain eye is extra sensitive to scaling errors in small shapes like text, which is why modern “smart” fonts use complex rules to compute specific pixel-size shapes. When you render at the wrong scale then rescale bitmap planes you invalidate a lot of this logic (the same is true to a much lesser extent for vector images).

That is basically why people working on text rendering radically disagreed with the decision to artificially clamp all displays to 96dpi circa 2020. It was done by desktop devs at the behest of web browsers devs because those devs did not want to bother with the complexity of accurate scaling.

Fractional scaling?

Posted Dec 11, 2025 10:34 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

Ultimately, it comes down to the fact that perfect reconstruction of the underlying image from samples requires you to evaluate an infinite impulse response filter to infinity, and that is impossible in finite time.

And note that the problem would go away completely if the pixel grid were finer; the reason we have this issue at all is that modern displays aren't high enough resolution to let you reduce the maximum possible error from a finite evaluation of the filter down below the threshold of visibility.

Indeed, the complex rules for computing specific pixel-size shapes are required because the error introduced by simply sampling the infinite resolution font to the screen is already visible, and therefore we need to choose visually inobtrusive errors, rather than just relying on the error being too small to be perceived.

Fractional scaling?

Posted Dec 11, 2025 13:03 UTC (Thu) by Wol (subscriber, #4433) [Link]

> And note that the problem would go away completely if the pixel grid were finer; the reason we have this issue at all is that modern displays aren't high enough resolution to let you reduce the maximum possible error from a finite evaluation of the filter down below the threshold of visibility.

Blame the TV :-)

I remember many many moons ago a rant from Linus about how his fancy new laptop had WORSE resolution, because they were replacing all the old hi-res laptop screens with new low-res (probably "HD Ready") TV screens.

Cheers,
Wol