Firefox 147 released

[Posted January 13, 2026 by jzb]

Version 147.0 of the Firefox web browser has been released. Notable changes in this release include support for the XDG Base Directory specification, enabling local network access restrictions for users with enhanced tracking protection (ETP) set to "Strict", and a fix that improves Firefox's rendering with GNOME on fractionally scaled displays. Firefox 147 also includes a number of security fixes, including several sandbox-escape vulnerabilities.

to post comments

Not GNOME-specific

Posted Jan 14, 2026 13:52 UTC (Wed) by daenzer (subscriber, #7050) [Link] (10 responses)

While the Linux-related item in the release notes might sound like it's Firefox catering to GNOME-specific behaviour, it's actually more like the opposite.

While v1 of the Wayland fractional scaling protocol doesn't mandate any specific rounding algorithm to be used by compositors & clients, a "stable rounding" algorithm with many desirable properties was documented in https://gitlab.freedesktop.org/wayland/wayland-protocols/... and implemented by mutter, wlroots and other compositors. The change in Firefox 147 helps with all compositors which implement this rounding algorithm.

Firefox 146, in contrast, used a slightly different algorithm implemented by KWin (in fact, 147 and newer still use that algorithm with KWin only). This resulted in blurry output at certain window sizes with other compositors which implement the "stable rounding" algorithm.

Not GNOME-specific

Posted Jan 15, 2026 13:09 UTC (Thu) by peniblec (subscriber, #111147) [Link] (9 responses)

Thanks a lot for these pointers! I understand better what I’m seeing now on Kubuntu 24.04, where the Firefox blur is noticeable on my 1920×1080@125% screen.

Firefox just got updated to 147,
that KDE dev update says support for wp-fractional-scale-v1 was merged in “Plasma 5.27” and “Qt 6” with “a chance it could be backported to KDE’s Qt 5.15 patch collection”,
on 24.04,
- kwin-wayland is 5.27.11,
- libqt5waylandclient5 is 5.15,
but apt source reveals the Qt change did not make its way to 24.04’s libqt5waylandclient5 🥲

Ah well. Resolutely waiting for the Raccoon, then.

Not GNOME-specific

Posted Jan 15, 2026 13:58 UTC (Thu) by daenzer (subscriber, #7050) [Link] (8 responses)

It sounds like your KWin should support the protocol, can check with "wayland-info -i fract".

Firefox doesn't use Qt, so that shouldn't matter.

If the blur is new in 147 and wasn't there yet in 146, it sounds like Firefox might not properly detect it's running on KWin on your system. What does "env | grep -i kde" say for you?

Not GNOME-specific

Posted Jan 15, 2026 17:11 UTC (Thu) by peniblec (subscriber, #111147) [Link] (7 responses)

Thanks for setting the record straight, and sorry for not applying my whole brain to the topic.

“wayland-info -i fact”

interface: 'wp_fractional_scale_manager_v1',             version:  1, name: 10

“As expected”, I suppose?

If the blur is new in 147 and wasn’t there yet in 146

I don’t think that’s the case, ISTR the blur being there for a while (I want to say, for as long as I’ve made the jump from {22.04 + GNOME + X11} to {24.04 + Plasma + Wayland}, but I don’t track these things as precisely as I perhaps should).

it sounds like Firefox might not properly detect it’s running on KWin on your system.

I would expect that it does, merely based on about:support saying “Desktop Environment” “kde” (and “Windows Protocol” “wayland”, if that needed confirmation).

What does “env | grep -i kde” say for you?

XDG_CONFIG_DIRS=/home/snip/.config/kdedefaults:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings
KGLOBALACCELD_PLATFORM=org.kde.kwin
XDG_SESSION_DESKTOP=KDE
XDG_CURRENT_DESKTOP=KDE
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=5
KDE_FULL_SESSION=true
KDE_APPLICATIONS_AS_SCOPE=1

(Cross-referenced with a random Firefox process’s /proc/…/env and that matches, for extra confirmation)

FWIW, it’s possible this blur I describe is not exclusive to Firefox? I just find it very noticeable there, whereas it does not bother me with e.g. Konsole or Emacs. Some other random factoids, in case they can shed some light: my setup is one built-in laptop screen 1920×1080@125%, plus one external 3840×2160@175%; Firefox looks crisp enough when I move its windows over to the external screen.

Not GNOME-specific

Posted Jan 16, 2026 9:14 UTC (Fri) by daenzer (subscriber, #7050) [Link] (6 responses)

> I don’t think that’s the case, ISTR the blur being there for a while (I want to say, for as long as I’ve made the jump from {22.04 + GNOME + X11} to {24.04 + Plasma + Wayland}

That indicates FIrefox isn't actually using the fractional scaling protocol for you. You can run it with the environment variable WAYLAND_DEBUG=client and look for wp_fractional_scale_manager_v1#<ID>.get_fractional_scale in the resulting stderr output to check.

Firefox only started enabling widget.wayland.fractional-scale.enabled (might want to check that on about:config) by default in 146 (IME it was quite buggy in older versions).

> FWIW, it’s possible this blur I describe is not exclusive to Firefox?

Any app which doesn't use the fractional scaling protocol will look blurry with any non-integral scaling factor. The fractional scaling protocol allows for pixel-perfect crisp output at any scaling factor.

> Firefox looks crisp enough when I move its windows over to the external screen.

Could just be that 175% results in less noticeable blur than 125%.

Not GNOME-specific

Posted Jan 20, 2026 7:42 UTC (Tue) by peniblec (subscriber, #111147) [Link] (5 responses)

(Sorry for the delayed answer, I have limited access to that setup. FWIW, I think you’ve given me enough pointers that I could probably reach the bottom of that rabbit hole by myself, so feel free to disengage!)

I don’t think that’s the case, ISTR the blur being there for a while (I want to say, for as long as I’ve made the jump from {22.04 + GNOME + X11} to {24.04 + Plasma + Wayland}

That indicates FIrefox isn’t actually using the fractional scaling protocol for you. You can run it with the environment variable WAYLAND_DEBUG=client and look for wp_fractional_scale_manager_v1#<ID>.get_fractional_scale in the resulting stderr output to check.

I do spot

  -> wp_fractional_scale_manager_v1@36.get_fractional_scale(new id wp_fractional_scale_v1@67, wl_surface@57)

in there; don’t know if that’s enough to draw conclusions (about:config says widget.wayland.fractional-scale.enabled is true).

Not GNOME-specific

Posted Jan 20, 2026 8:35 UTC (Tue) by daenzer (subscriber, #7050) [Link] (4 responses)

> I do spot
>
> -> wp_fractional_scale_manager_v1@36.get_fractional_scale(new id wp_fractional_scale_v1@67, wl_surface@57)
>
> in there; don’t know if that’s enough to draw conclusions (about:config says widget.wayland.fractional-scale.enabled is true).

That seems to confirm Firefox is using the protocol, so blur is unexpected.

Maybe it's a KWin 5.x specific issue. E.g. maybe it used yet another slightly different rounding algorithm, or didn't align sub-surface pixels to the physical pixel grid. Is the blur uniform, or does it vary across one or both window axis like a wave?

Not GNOME-specific

Posted Jan 20, 2026 18:08 UTC (Tue) by peniblec (subscriber, #111147) [Link] (3 responses)

Maybe it’s a KWin 5.x specific issue. E.g. maybe it used yet another slightly different rounding algorithm, or didn’t align sub-surface pixels to the physical pixel grid. Is the blur uniform, or does it vary across one or both window axis like a wave?

I would say “uniform”? I’ve taken a couple of screenshots, and to my surprise they do seem to showcase the issue?

First, comparing whole-workspace screenshots of

two Firefox windows showing the same content:
- the left window (built-in screen @125%) has these half-opacity 1-2-pixel lines above & below solid stretches, e.g. the brown rounded heading backgrounds, the “L” in “Welcome to LWN.net”;
- the right window (external monitor @175%) shows no such lines around these solid horizontal stretches.
two Konsole windows showing the same content: funnily enough, the symptom seems reversed, tho FWIW I find the half-opacity lines (e.g. around man’s press h for help or q to quit inverse-video decoration) less aggravating on the external monitor…

And the more bizarre comparison, perhaps:

a maximized Firefox window, on the built-in monitor,
that same window, on the same monitor, with the same 125% setting, with the external monitor unplugged.

The blur on the built-in monitor just goes away if I disconnect the external monitor. That matches my experience (that I hadn’t really thought twice about) that roaming with that laptop at 125% feels just fine, but that same setting feels off once docked.

Not sure how reliable those observations are; given all the software layers involved¹, I don’t hold much faith that Spectacle should accurately reproduce what my eyes perceive; still, since the screenshots did show something, figured I’d show them.

¹ Case in point, the dimensions Spectacle chooses for screenshots of the built-in screen confuse me: the screen is consistenly always 1920×1080@125%, but its dimensions in screenshots are 1920×1080 when shooting just that screen, and 2688×1512 when shooting both screens.

Not GNOME-specific

Posted Jan 20, 2026 18:46 UTC (Tue) by excors (subscriber, #95769) [Link] (2 responses)

In your second set of screenshots, it's not just Firefox, the whole Plasma taskbar is slightly different - it looks like everything has been shifted downwards by exactly 0.5 pixels. The taskbar icons are already quite blurry, and the shift makes some of them better and some of them worse; but it makes Firefox consistently worse.

I wonder if it depends on the offset between the two displays? The 1920x1080 display has origin (0,0) when it's the only monitor, but perhaps an odd number like (0,123) when the second monitor is added, and maybe that confuses the scaling maths. If that was the case, perhaps changing the offset between them (e.g. so the top edges are aligned) might improve things. (I have no knowledge of the software though, I'm just guessing based on the visible behaviour.)

Not GNOME-specific

Posted Jan 21, 2026 8:17 UTC (Wed) by daenzer (subscriber, #7050) [Link] (1 responses)

Agreed, looks like the blur is due to the vertical position of the built-in output not being aligned to the physical pixel grid, i.e. a KWin issue.

I guess it's unlikely this will be fixed in KWin 5.x at this point, so I'd suggest:

* See if you can manually round the position to an integer in a configuration file.
* Maybe try if it can still happen with KWin 6.x, and report it upstream if so.

Not GNOME-specific

Posted Jan 22, 2026 7:40 UTC (Thu) by peniblec (subscriber, #111147) [Link]

Kudos to you both, the blur does go away if I align both monitors to "y": 0! Didn’t mean to nerd-snipe anyone when I answered daenzer’s initial comment, so thanks ever so much for lifting that curse off my screen 🙇

(FTR, did not need to locate config files - just aligned both monitors along the top edge in Plasma’s Display Configuration GUI until both screens showed (…, 0). Curiosity got the best of me tho and FTR², the config files seem to be under ${XDG_DATA_HOME:-~/.local/share}/kscreen; thank Eris for find -newermt '2 minutes ago')

It’ll be interesting to see how things evolve in 6.x. Will patiently wait for 26.04 for that tho; trying to minimize boat-rocking on that workstation. Prefer to use my Tumbleweed home rig for reproducing & reporting bugs upstream, tho that desktop sports a simpler setup (one single “LoDPI” monitor) which has proved less janky thus far.

Again, thanks a bunch for your time!

1-0 User Agents vs. Surveilance Platforms

Posted Jan 17, 2026 16:10 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (1 responses)

> enabling local network access restrictions

This is very welcome since Facebook, Instagram, and Yandex were caught exploiting this vulnerability to track users without their consent on Android last June. Chrome added LNA restrictions in version 142 (last October), and there's also the option of running firejail --net=eth0 firefox.

1-0 User Agents vs. Surveilance Platforms

Posted Jan 17, 2026 19:17 UTC (Sat) by Wol (subscriber, #4433) [Link]

Hmmm - "informed consent". I hope they didn't enable that in Europe, especially as it was bypassing security controls that were supposed to prevent it ...

Cheers
Wol