1753601 - [wayland] Web Extension popup content is trimmed with fractional scaling

Status: ASSIGNED

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

Description

[Michel Le Bihan]

Hello,

When using Firefox with MOZ_ENABLE_WAYLAND=1 on GNOME on Wayland with fractional scaling (125%), WebExtension popup content is trimmed as can be seen on the attached screenshots.

I'm not sure if this is a Firefox bug, but since it affects multiple extensions, I guess it might be.

Comment 1

[Michel Le Bihan]

Attachment: user-agent-switcher-100.png

Comment 2

[Michel Le Bihan]

Attachment: user-agent-switcher-125.png

Comment 3

[Michel Le Bihan]

Attachment: privacy-badgr-100.png

Comment 4

[Michel Le Bihan]

Attachment: privacy-badger-125.png

Comment 5

[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 revert this change in case you think the bot is wrong.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Reporter asked how to investigate this, so dumping some details below:

So, if this only happens on WebExtension popups, I'd look at this code which is what takes care of sizing the popups to the right size, and the relevant parent process code which is this.

But since it only happens on Wayland (presumably?), it might be a bug in the Widget code (so this and related code). Might be worth reproducing the bug with MOZ_LOG=WidgetPopup:5 in the environment and see if the resize dimensions match your expectations. Might be a missing GDK to Device pixels or vice versa?

Comment 7

[Michel Le Bihan]

The size of the content of the popup is correct. The problem is with the size of the popup itself. The height does not grow with fractional scaling. On XWayland, where the window is simply scaled and blurry, the popup height is much bigger.

With 100% scaling: nsWindow::NativeMoveResizeWaylandPopup 1270,108 -> 610 x 497
With 125% scaling: nsWindow::NativeMoveResizeWaylandPopup 886,108 -> 610 x 418

Comment 8

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

I think it's because we report wrong screen size on Wayland when fractional scale is used. There are still some bits left so we use screen size on Wayland to trim popup sizes (although we should not do that on Wayland).

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

MOZ_LOG="WidgetScreen:5" log may help to get some info about screen sizes. Also can you attach picture of whole screen + popup, not just popups?

Comment 10

[Michel Le Bihan]

Attachment: firefox-100.png

Comment 11

[Michel Le Bihan]

Attachment: firefox-125.png

Comment 12

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Yes, I think with 125% scale we report the screen size as with 100%.

Comment 13

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Just to be sure, which FF version do you run?

Comment 14

[Michel Le Bihan]

"version": "99.0a1",
"buildID": "20220209190711",

but stable is also affected

Comment 15

[Michel Le Bihan]

Yes, I think with 125% scale we report the screen size as with 100%.

Isn't that correct? shouldn't only the scale change?

I see, but I'm not sure if that's important

D/WidgetScreen Monitor 0 [0 0 -> 1920 x 1080 depth 32 content scale 1.000000 css scale 1.000000 DPI 161.364700]
D/WidgetScreen Monitor 0 [0 0 -> 1920 x 1080 depth 32 content scale 2.000000 css scale 2.000000 DPI 161.364700]

Comment 16

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Which distro do you run? Please attach full log from MOZ_LOG="WidgetScreen:5".

Comment 17

[Michel Le Bihan]

Debian testing Bookworm

Comment 18

[Michel Le Bihan]

Attachment: firefox-100-log.txt

Comment 19

[Michel Le Bihan]

Attachment: firefox-125-log.txt

Comment 20

[Michel Le Bihan]

This issue seems very similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1672591

Comment 21

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Looks like a fix in Bug 1718727 is not complete.

Comment 22

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Can you please test with latest nightly?
Thanks.

Comment 23

[Michel Le Bihan]

The popup content is still trimmed on 100.0a1 build 20220401190316

Comment 24

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Thanks. Please run with MOZ_LOG="WidgetPopup:5" env variable, open the trimmed popup and attach the log here.

I wonder if we hit this code:
https://searchfox.org/mozilla-central/rev/78c8fd2e91ca0f4f85ed11fa2a19564f50e75b34/layout/xul/nsMenuPopupFrame.cpp#1575

Comment 25

[Michel Le Bihan]

Attachment: log_2022-04-04.txt

Comment 26

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Hm, interesting - it may come from some initial popup size calculation, I don't see any adjustments.

Comment 27

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Seems to be related to layout popup code init where we initially shrink popup due to screen size.

Comment 28

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Emilio, do you know if we put screen size somewhere into layout reflow? I see the prefSize here:
https://searchfox.org/mozilla-central/rev/26a1b0fce12e6dd495a954c542bb1e7bd6e0d548/layout/xul/nsMenuPopupFrame.cpp#574
is already reduced.
Thanks.

Comment 29

[Emilio Cobos Álvarez (:emilio)]

Not directly, I don't think. But there's some front-end code which might be related... Do you know how can I repro this on Fedora? I can poke if you want.

Comment 30

[Michel Le Bihan]

Do you know how can I repro this on Fedora? I can poke if you want.

1. Run gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" (or add it to the list if you have other experimental features enabled)
2. Restart
3. Control Center (Settings) -> Monitors -> Scale

Comment 31

[Emilio Cobos Álvarez (:emilio)]

Right, I've done that, but a scale of 125% doesn't show the issue for me. I'm on a HiDPI monitor, so I tried 250% instead, bug any scale from >200% and <= 300% don't work because of https://gitlab.gnome.org/GNOME/gtk/-/issues/4746. A scale of 350% showed working popups too (tried the UA switcher one which seemed to be the one you were hitting issues with).

Comment 32

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Yes, that would be great. I can reproduce it clearly on Fedora 35/Gnome. Use 125% scale with 1920 x 1080 screen resolution (yes, it may be a bit blurry :)) but it reproduces fine in such setup.

Comment 33

[Emilio Cobos Álvarez (:emilio)]

Attachment: Screencast of emilio trying to repro the bug on that setup

Still nothing, see screencast: Maybe mutter bug already fixed upstream? I'm on mutter-42.0-3.fc37.src.rpm...

Comment 34

[Emilio Cobos Álvarez (:emilio)]

Will try to repro on a Fedora 35 image, but debugging on a VM is kind of annoying (rr doesn't work :)).

Comment 35

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

I tested Fedora 37 but it fails to start in Wayland mode. I tested Fedora 36 (has the same mutter package) and it's broken. Even hamburger menu is shrank with scrollbar (although it should not be).

Comment 36

[Emilio Cobos Álvarez (:emilio)]

I can repro on 35, but again not on 37...

Comment 37

[Emilio Cobos Álvarez (:emilio)]

Ah! I can repro on 37 iff I downscale both screens, not just the one Firefox is on... Wat?

Anyways, will look.

Comment 38

[Emilio Cobos Álvarez (:emilio)]

Yeah, something like this trivially fixes it:

diff --git a/browser/components/customizableui/PanelMultiView.jsm b/browser/components/customizableui/PanelMultiView.jsm
index 7c747f7681700..26b99a66e085a 100644
--- a/browser/components/customizableui/PanelMultiView.jsm
+++ b/browser/components/customizableui/PanelMultiView.jsm
@@ -1161,6 +1161,7 @@ var PanelMultiView = class extends AssociatedToNode {
   }
 
   _calculateMaxHeight(aEvent) {
+    return 100000;
     // While opening the panel, we have to limit the maximum height of any
     // view based on the space that will be available. We cannot just use
     // window.screen.availTop and availHeight because these may return an

Comment 39

[Emilio Cobos Álvarez (:emilio)]

So, Martin, after bug 1763184, the generic ScreenGetterGtk code seems to work on GNOME + Wayland just fine (i.e., I no longer reproduce stuff like bug 1661540).

Anyways, this is a bug with ScreenGetterWayland, where we're not accounting for the GTK scale correctly. I have two monitors, one configured with 1980x1080 @ 125% scaling, and one with 3840x2160 @ 200% scaling. I see no obvious way to get the right CSS scaling on the sizes but I might be missing something.

[Parent 374799: Main Thread]: D/WidgetScreen ScreenGetterWayland created
[Parent 374799: Main Thread]: D/WidgetScreen Add Monitor ID 4 num 0
[Parent 374799: Main Thread]: D/WidgetScreen Add Monitor ID 5 num 1
[Parent 374799: Main Thread]: D/WidgetScreen wl_output: geometry position 0 0 physical size 600 340, subpixel 0, transform 0
[Parent 374799: Main Thread]: D/WidgetScreen wl_output: mode output size 1920 x 1080 refresh 60000
[Parent 374799: Main Thread]: D/WidgetScreen wl_output: scale 2
[Parent 374799: Main Thread]: D/WidgetScreen done
[Parent 374799: Main Thread]: D/WidgetScreen Refreshing screens
[Parent 374799: Main Thread]: D/WidgetScreen Monitor 0 [0 0 -> 1920 x 1080 depth 32 content scale 2.000000 css scale 2.000000 DPI 80.682350]
[Parent 374799: Main Thread]: D/WidgetScreen Monitor 1 [0 0 -> 0 x 0 depth 32 content scale 0.000000 css scale 0.000000 DPI 96.000000]
[Parent 374799: Main Thread]: D/WidgetScreen Refresh screens
[Parent 374799: Main Thread]: D/WidgetScreen Refreshing all ContentParents
[Parent 374799: Main Thread]: D/WidgetScreen wl_output: geometry position 1536 0 physical size 610 350, subpixel 0, transform 0
[Parent 374799: Main Thread]: D/WidgetScreen wl_output: mode output size 3840 x 2160 refresh 59996
[Parent 374799: Main Thread]: D/WidgetScreen wl_output: scale 2
[Parent 374799: Main Thread]: D/WidgetScreen done
[Parent 374799: Main Thread]: D/WidgetScreen Refreshing screens
[Parent 374799: Main Thread]: D/WidgetScreen Monitor 0 [0 0 -> 1920 x 1080 depth 32 content scale 2.000000 css scale 2.000000 DPI 80.682350]
[Parent 374799: Main Thread]: D/WidgetScreen Monitor 1 [1536 0 -> 3840 x 2160 depth 32 content scale 2.000000 css scale 2.000000 DPI 156.754288]
[Parent 374799: Main Thread]: D/WidgetScreen Refresh screens
[Parent 374799: Main Thread]: D/WidgetScreen Refreshing all ContentParents

Do you know when bug 1661540 was fixed on Mutter / Gtk? Maybe we can just remove ScreenGetterWayland nowadays altogether. I guess we'd need to test common versions of Distros to sanity-check those kinds of bugs don't re-appear but...

Comment 40

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

The problem is that partial scale is always reported as upper scale. So 1980x1080 @ 125% is reported as 1980x1080 scale 2 and that's reported for all scales between 100% and 200% - so 1980x1080 @ 125% , 1980x1080 @ 150%, 1980x1080 @ 175% and 1980x1080 @ 200% are reported by Wayland as 1980x1080 scale 2. The only hint is the 'geometry position 1536'.

The only way how to fix that is IMHO don't use any popup restrictions on Wayland and let move-to-rect to do the work.

Comment 41

[Emilio Cobos Álvarez (:emilio)]

I disagree, without fixing the screen getter code screen.height in JS and so on are completely busted and report too small values.

Comment 42

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1753601 - Use xdg_output_manager to get logical sizes in GNOME+Wayland. r=stransky

This is what GTK does, and fixes the issue. But again I think long-term
we should just remove ScreenGetterWayland. Nowadays ScreenGetterGTK
works fine on GNOME as well, and we only use ScreenGetterWayland there.

Comment 43

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

I think I see it even without fractional scaling. Install https://addons.mozilla.org/en-US/firefox/addon/youtube-high-definition/ & use screen with 4K 200% scale and the popup is shrank although it may fit the window.

Tested on latest trunk & Fedora 35.

Comment 44

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

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

I think I see it even without fractional scaling. Install https://addons.mozilla.org/en-US/firefox/addon/youtube-high-definition/ & use screen with 4K 200% scale and the popup is shrank although it may fit the window.

Tested on latest trunk & Fedora 35.

This doesn't look Wayland specific, I see the same on X11.

Comment 45

[Michel Le Bihan]

I noticed that the device list in Responsive Design Mode is also trimmed with fractional scaling.

Comment 46

[Michel Le Bihan]

Hello,
I noticed that setting widget.wayland.fractional_buffer_scale to 1.25 resolves issues in Responsive Design Mode, but has no effect on web extensions popups.

Comment 47

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

The following patch is waiting for review from an inactive reviewer:

ID	Title	Author	Reviewer Status
D143033	Bug 1753601 - Use xdg_output_manager to get logical sizes in GNOME+Wayland. r=stransky	emilio	stransky: Resigned from review

:emilio, could you please find another reviewer?

For more information, please visit auto_nag documentation.

Comment 48

[Emilio Cobos Álvarez (:emilio)]

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

I think I see it even without fractional scaling. Install https://addons.mozilla.org/en-US/firefox/addon/youtube-high-definition/ & use screen with 4K 200% scale and the popup is shrank although it may fit the window.

That is because the front-end has a hard-coded max of 600px for extension popups: https://searchfox.org/mozilla-central/rev/108c7843696fdf951083889d6fb858953139be96/browser/components/extensions/ExtensionPopups.jsm#402

But web-exposed screen.height and so on should still be right. So this is not a bug, that's by design.

I still think the patch is probably ok or at least worth doing / removing ScreenGetterWayland (given ScreenGetterGTK behaves correctly now). Ideally, ScreenGetterGTK will magically work in the future when gtk deals with the fractional scale.

Comment 49

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #48)

I still think the patch is probably ok or at least worth doing / removing ScreenGetterWayland (given ScreenGetterGTK behaves correctly now). Ideally, ScreenGetterGTK will magically work in the future when gtk deals with the fractional scale.

We may stick with a method which reports bigger screen values to avoid popup shrink.

Comment 50

[Michel Le Bihan]

Hello,
Today I tested Plasma desktop (Wayland) on Fedora 37 and I noticed that this issue is not present when using Firefox on KDE Plasma with fractional scaling, but I can still reproduce it on GNOME with fractional scaling.