1849109 - Context menu broken with widget.wayland.fractional-scale.enabled

Status: RESOLVED FIXED

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

Description

[05kraken]

Attachment: Screenshot_2023-08-17-14-19-55.png

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

Steps to reproduce:

Set widget.wayland.fractional-scale.enabled = true, restart firefox. I'm running wayland on hyprland window manager.

Actual results:

Right click to open context-menu. The context-menu size is inconsistent. Also application menu is broken. Also firefox window is blurry.

Expected results:

Context-menu size should be consistent.

Comment 1

[05kraken]

Attachment: Application menu always appear on the midle of window.

Comment 2

[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 3

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

Is that a recent regression?

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

Comment 4

[Emilio Cobos Álvarez [:emilio]]

That pref was just added in bug 1767142 so... :)

Comment 5

[05kraken]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)

Is that a recent regression?

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

I saw this issue on the same day, this widget.wayland.fractional-scale.enabled flag was added.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Which scaling are you using in comment 0?

Comment 7

[05kraken]

Currently it is set as auto in my hyprland config.
But if i set scaling to 1.25 manually this issue persist.
This issue doesn't happen If scaling is set to 1.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

I can repro on KWin too. Robert do you see something obvious?

Comment 9

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

Set release status flags based on info from the regressing bug 1767142

Comment 10

[[object Object]]

I can reproduce on KWin as well (on my framework laptop), but not on my desktop PC (even though they're both using fractional scaling)

Comment 11

[Ye Jingchen]

I can also reproduce this in kwin using 135% scaling factor. The fun part is that changing Firefox window size sometimes gives pixel perfect result, especially when changing by 1px each time. Changing window size in horizontal or vertical "calibrates" the corresponding direction, and when both are "calibrated" the final result is pixel perfect. Pixel perfect image only appears in web page, not the window chrome or context menus.

BTW, Qt 6 applications don't have this issue as far as I can tell.

Comment 12

[Ye Jingchen]

(In reply to Ye Jingchen from comment #11)

Pixel perfect image only appears in web page, not the window chrome or context menus.

Small correction: the window chrome is pixel perfect too. Only menus are still blurry.

Comment 13

[Celeste Liu [:Coelacanthus]]

I can also reproduce this in kwin 5.27.7 using 175% scaling factor.

Comment 14

[Michel Le Bihan]

I can reproduce it on Fedora Rawhide with GNOME and fractional scaling with a 125% scaling factor.

# System Details Report
---

## Report details
- **Date generated:**                              2023-08-21 21:48:29

## Hardware Information:
- **Hardware Model:**                              Lenovo ThinkPad E14 Gen 2
- **Memory:**                                      16.0 GiB
- **Processor:**                                   11th Gen Intel® Core™ i5-1135G7 × 8
- **Graphics:**                                    Intel® Xe Graphics (TGL GT2)
- **Disk Capacity:**                               (null)

## Software Information:
- **Firmware Version:**                            R1EET56W(1.56 )
- **OS Name:**                                     Fedora Linux 40 (Workstation Edition Prerelease)
- **OS Build:**                                    (null)
- **OS Type:**                                     64-bit
- **GNOME Version:**                               45.beta.1
- **Windowing System:**                            Wayland
- **Kernel Version:**                              Linux 6.5.0-0.rc6.20230818git0e8860d2125f.47.fc40.x86_64

Comment 15

[Michel Le Bihan]

Attachment: Firefox_menu.png

Comment 16

[Robert Mader [:rmader]]

Yep, that was a known issue with fractional scaling even before adding the protocol support. If you look at the positioning, it appears that the coordinates are too small by a certain factor - roughly the scaling factor, but maybe also something slightly bigger / slightly more complex to compute.

IIRC we use the Wayland positioning protocol via GTK, maybe we're missing something there.

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Yeah it seems like gtk still uses the int scale factor, but we're sending it fractionally-scaled coordinates... I'm not a fan of having to introduce another coordinate space for this :'(

Comment 18

[Edward O]

Also reproducing on KDE neon stable, Plasma/KWin 5.27.7, fractional scale 125%.

• As mentioned by reporter context menu is too small (with scrolling inside), wrongly positioned, and relocates. App menu is misplaced as well.

• The window chrome is slightly blurry but acceptable -- but it's also the same size as with widget.wayland.fractional-scale.enabled = false,
  is that expected?
• The web content is scaled but very blurry

If window chrome is not scaled, and since web content could already have a default zoom set, what is the aim of this toggle right now? (I'm asking to know what I should be testing, I appreciate the effort!)

Comment 19

[Robert Mader [:rmader]]

If window chrome is not scaled, and since web content could already have a default zoom set, what is the aim of this toggle right now?

Optimally this setting should have no visual effect at all (or things should be minimally sharper in some cases). The main goal is to improve performance by reducing overdraw.

Short example: on a 1920x1080 screen at 125%, without this setting Firefox (or any Wayland app without support for the protocol) would draw a buffer of 3072x1728 (= 1536 * 2 x 864 * 2 = 1920/1.25 * 2 x 1080/1.25 * 2) in fullscreen mode, which then gets scaled down to 1920x1080 by the compositor. With this protocol the buffer size would be 1920x1080. That's roughly 60% less pixels to be drawn per full redraw.

Comment 20

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

Set release status flags based on info from the regressing bug 1767142

Comment 21

[Michel Le Bihan]

Attachment: build_20230903210251.png

Comment 22

[Michel Le Bihan]

It's even worse on build 20230903210251 now.

Comment 24

[xgreenlandforwyy]

Report from Firefox 118 shipped by Debian sid, Plasma/KWin 5.27.7 shipped by Debian Bookworm, fractional scale 120%:

Not only Context menu, but also some drop down list are also misplaced. Go to settings and click the fontsize selection as an example.

Comment 25

[nkwkelvin]

I can reproduce the problem with Firefox 120 on KDE Plasma 5.27.9.

Also, it looks like the text is still blurry with fractional scaling when I compare the screenshot with Firefox/X11 side-by-side. about:support still shows that my display is "4388x2468@60Hz scales:2.000000|2.000000" instead of the supposedly "3840x2160@60Hz scales:1.750000|1.750000".

But the good thing is that window.devicePixelRatio shows 1.75 correctly. YouTube viewport is also correct.

I feel like the text rendering part is still using integer scaling?

Comment 26

[Matthew Swabey]

Attachment: 2024-01-04 Firefox about:support

About:support from browser suffering from bug 1849109

Comment 27

[Matthew Swabey]

I can reproduce this with

widget.wayland.fractional-scale.enabled = true

on Firefox 120, see bug attachment https://bug1849109.bmoattachments.org/attachment.cgi?id=9371116 for complete about:support.

It affects the "File Edit View..." menu dropdown, the bookmark toolbar dropdowns, Bitwarden add-on menu, all being either not rendered at all or cutoff too small.

Comment 28

[Matthew Swabey]

Doh, forgot to add on KDE on Kubuntu:

Operating System: Kubuntu 23.10
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.10
Kernel Version: 6.6.8-060608-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 6850H with Radeon Graphics
Memory: 23.2 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 21D5S0CA00
System Version: ThinkPad Z16 Gen 1

Comment 29

[Bartosz Bartyzel]

Attachment: ff_menu_cutoff.webm

Using a nightly build built on my PC I was able to reproduce this on Debian Testing (Gnome 46).
I used the debugger to trace the change sizes of the popup box - this is visible in the video.
Does this seem more like a problem with Gecko or rather the composer (mutter)? Any suggestions on where to look are welcome.

Comment 30

[Bartosz Bartyzel]

Attachment: ff_display_dimensions

Firefox reports display size scaled by a factor of 1.33.
The scale factor is set to 1.5 (150%)
Calculations and numbers included in the screenshot.
I'm not sure why the 'scales' option is printed as 2.0 on the about:support screen.

This problem is visible with widget.wayland.fractional-scale.enabled set either way.

Comment 31

[Calvin Walton]

Note that the issue with window chrome/contents being blurry (misaligned with the pixel grid) is bug 1849092 and it is probably not related to the problems with position or size of pop-up menus.

Comment 32

[Bastian Gruber]

I faced the same issue, and I "accidentally" solved it (at least for me, locally).

I started firefox -p from the command line, and created a new profile. The appearing Firefox instance didn't face the same bug and all menus scaled in the right way. I switched completely to the new profile, and somehow, the scaling issue is gone.

Comment 33

[Emilio Cobos Álvarez [:emilio]]

Well, because widget.wayland.fractional-scale.enabled is experimental and thus off by default right? You must've somehow turned it on on your original profile

Comment 34

[Bastian Gruber]

Ah, that's true. One interesting observation though: I don't see a difference in scaling at all. My Wayland environment scales to 1.5. But both Firefox instances (fractional-scale.enabled true and false) look identical.

Comment 35

[Emilio Cobos Álvarez [:emilio]]

Yeah, that's the idea. fractional-scale.enabled should be more efficient. Without it we effectively render at 2x resolution, and the compositor down-scales, IIRC. Which means it's the same end result, but more work.

Comment 36

[Robert Mader [:rmader]]

Yeah, I'm sorry for not having followed up here yet - the current implementation was rather a PoC than production ready. The good news is that in Gnome-Shell we just landed a big rework to make fractional scaling more usable for the upcoming 47 release[1] and GTK4 uses a similar approach aswell now. So I hope that will increase my or somebody else's motivation to work on this feature and get it over the line (i.e. enable it by default).

1. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567

Comment 37

[lilydjwg]

While it might not have a very visible difference for Latin letters and the like, downscaling from 2x to 1.25x makes Chinese characters blurry. Also a one-pixel border hollow box may have different border thickness. That's why I switched from 1.25x to 1x and adjust font size / text scale factor instead.

Comment 38

[Calvin Walton]

Unless I'm missing something, the changes in mutter#3567 don't seem to be relevant to Firefox's fractional scaling support? Firefox is using Wayland natively here, not Xwayland.

Many of the issues with Firefox's existing implementation of fractional scaling seem to stem from the fact that Firefox is still using Gtk3, and then hacking fractional scaling on top of Gtk3 by having the browser engine render to a fractionally scaled Wayland subsurface. From my point of view, it seems likely that some issues with with context menu positioning or sizing stem from errors in the conversion between the coordinate systems used by the toplevel window from Gtk (which is using integer scaling) and Firefox's subsurface (which is using fractional scaling)?

Comment 40

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1849109 - Fix popup sizing with fractional scales. r=stransky

We probably need more fixes on top, I see sometimes we get stuck in a
move-to-rect loop (probably because our gtk call doesn't know about the
fractional scale).

But this fixes the sizing and positioning at least.

Comment 41

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1849109 - Prevent move-to-rect loops with fractional scale. r=stransky

See comment. Without it we might get slightly different bounds which
gets us into a resize loop.

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8428dc430fa4
Fix popup sizing with fractional scales. r=stransky

Comment 46

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8428dc430fa4

Comment 47

[Emilio Cobos Álvarez [:emilio]]

The other patch is also needed.

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8ea92cb66a90
Prevent move-to-rect loops with fractional scale. r=stransky

Comment 49

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/8ea92cb66a90