1952646 - [KDE][Plasma 5] scaling broken on high DPI screen linux

Status: RESOLVED DUPLICATE of bug 1992198

(Core :: Widget: Gtk, defect, P3)

Description

[Casteyde]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Using KDE on Slackware Linux
Using plasma 5.23.5, Qt 5.13.3, Wayland
Screen resolution 2560x1600, Scaling 150%
Starting Firefox 135

Actual results:

Firefox window is hugely zoomed.
Click on tabs, URL bar, etc. do not target the right widget.
This problem does not occur with Firefox 134 nor if I use scaling 100%.

Expected results:

Firefox should render with the proper size, as was done in version 134.
See provided screenshots.
This report was done with Firefox 134 as 135/136 are unusable.

Comment 1

[Casteyde]

Attachment: KDE configuration screen

Comment 2

[Casteyde]

Attachment: Screenshot of Firefox version 134 with scaling 150%

Comment 3

[Casteyde]

Attachment: Screenshot of Firefox 135 with scaling 150%

Comment 4

[Casteyde]

Attachment: Screenshot of Firefox 135 with scaling 100%

Comment 5

[Casteyde]

Attachment: Screenshot of Firefox 134 with scaling 150% (desktop included)

Comment 6

[Casteyde]

It is as if the UI is scaled 150% twice (once by desktop, once by firefox/toolkit)

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 9

[Casteyde]

mozregression has identified the following commit:
3:42.82 INFO: Narrowed integration regression window from [0b628a45, 25a4dff1] (3 builds) to [0b628a45, d89c5990] (2 builds) (~1 steps left)
3:42.82 INFO: No more integration revisions, bisection finished.
3:42.82 INFO: Last good revision: 0b628a45f2db90437ae0c5800b8a5ce189a0b8b7
3:42.82 INFO: First bad revision: d89c599022b9b8970d5008ea1524e3164bdae5a0
3:42.82 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=0b628a45f2db90437ae0c5800b8a5ce189a0b8b7&tochange=d89c599022b9b8970d5008ea1524e3164bdae5a0

This tool was fantastic to do the bisection :-)
Best regards

Comment 10

[Casteyde]

Attachment: git bisect result

For more information, I've git bisected the commits and here is the result:

Comment 11

[Casteyde]

Comment on attachment 9477555 [details]
git bisect result

Indeed, looking at code change, I guess the faulting commit is either
30f0cd81dfe4282994e287553e462cdf9e14078f
Make nsWindow to use WaylandSurface and new VSync interface r=emilio
or
34e21de95d99b8ee17a5e45092ff3bfb49da7d76
Move wl_surface management from MozContainerWayland to WaylandSurface and reference it from MozContainerWayland r=emilio

because the scale factor calculation has been changed from
gint scale = GdkCeiledScaleFactor();
to
double scale = FractionalScaleFactor();

Please note I'm using Wayland.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

I see. That may be a regression from fractional scale enabled by default.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Have you set widget.wayland.fractional-scale.enabled to true at about:config?
Thanks.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Also do you see that with clean profile? (I think so but asking to make sure).
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Test_Firefox_with_a_new_profile
Thanks.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Tested on Fedora 42 / KDE / GNOME and I don't see it. I checked Firefox 134 and 135/6 and both looks the same with KDE scale 150%.
It may be a bug in Plasma 5.X, please try 6.X line.
Thanks.

Comment 16

[Casteyde]

For the previous questions:

1. Of course, I've tried on a new profile (indeed a new user account created from scratch).
   It was the same result.
2. I've also tried some variations on widget.wayland.fractional-scale.enabled.
   For v134, it works whatever I set for this parameter. I doubt it was the change to default.
   For v135, I didn't manage to access about:config because the browser is unusable (input are not redirected to zoomed areas correctly).
3. Sadly, Slackware current is still not on plasma 6 so I cannot check it.
   I've downloaded Kubuntu images and tried to boot on them, but sadly the kernel hangs at startup on bluetooth power mode and the live ISO freeze totally. This is a kernel problem I also reported and for which a workaround was given to me for my slack.
   I don't think I will take time to build new KDE packages with plasma 6 and risk to break my OS for now.
   However I can do some smaller checks of course if necessary.
   Thanks

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Okay, please update when you have Plasma 6.X ready.

Comment 18

[Tem PQD [:tempqd]]

On Nightly, toggling widget.wayland.fractional-scale.enabled to true does trigger this bug for me too. But closing and reopening the window fixes it. Tested on KDE git master (6.5 dev), Wayland, Tumbleweed. Plasma global desktop scaling set to 150%.

Comment 19

[Tem PQD [:tempqd]]

Attachment: Recording of Nightly on KDE Plasma git master (6.6 dev)

I see this on KDE git master (Plasma 6.6 dev). Does the [Plasma 5] in the title mean Plasma 5 only?

I've attached a video of some more glitching with it.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Should be fixed in latest nigtly. Also scaling should be fixed by Bug 1992198.

Comment 21

[Martin Stránský [:stransky] (ni? me)]

If you switch widget.wayland.fractional-scale.enabled you need to restart browser to work correctly. It relocates all surfaces sizes.

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Tem PQD, please test after browser restart.

Comment 23

[Tem PQD [:tempqd]]

Attachment: Glitch after toggling false->true on Try 9130cbf4 build

Browser restart indeed fixes the issue on Nightly and the build from Bug 1992198, and also on stable release though (as in #c18).

As for the glitches when toggling, it seems no change in behavior on Nightly 2025-10-11 for me (still behaves like in the screen recording).

Testing the build from Bug 1992198 there is a change in behavior when toggling, but seems not fixed still. Instead of a click at the right/bottom edges of the window resulting in the window being cropped, now clicks go through that area and the window remains larger than intended, even showing strange preview in Task Switcher. Screenshot attached.

If the above is expected, that's fine for now I think. The glitches when toggling are pretty minor and IMO okay to not prioritize for now (unless they're a symptom of deeper rendering issues).

Comment 24

[Martin Stránský [:stransky] (ni? me)]

We're not going to fix widget.wayland.fractional-scale.enabled toggle behavior - users are not expected to flip that. Also we can't use static pref as we read it too early at Screen init code. I hope to make widget.wayland.fractional-scale.enabled:true default in short term so that may be obsoleted anyway.

Let's track all other changes at Bug 1992198.

Comment 25

[Casteyde]

Hello
Indeed, nightly build doesn't change anything as far as I'm concerned, whatever the fractional-scale.enabled toggle value.
The browser is still rendered too big, with mouse input not directed to the right controls.
I've not upgrade my KDE setup yet however.
I'm therefore not sure my bug report is the same as the one that has been fixed.