1731489 - [Wayland] Firefox confused by HiDPI scaling, freezing app for seconds after switching to workspace with it

Status: RESOLVED WORKSFORME

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

Description

[Mart Raudsepp]

I use GNOME with Firefox Wayland, and I've always had it have trouble with my 200% HiDPI scaling, but with upgrade to Firefox 92, it became worse.

Before it was mostly just what seems described as bug 1708924, but after the upgrade, it goes spinning the CPU each time I switch to a workspace that has any Firefox windows, freezing all Firefox windows for 5+ seconds until it seemingly figures out the DPI situation - sometimes I visually see it drawing without the scaling instead to the top left quarter of the screen, with some visual blinking between that and slightly smaller or larger display area.
Once it settles and I can use Firefox again after 5-15 seconds, it has a tendency to misunderstand the window borders, so if I drag select any text from the bottom half of the monitor (Firefox is maximized) and go down a bit, it starts quickly scrolling the whole page, instead of just selecting where I dragged, because it seems to think I've hit the window border and behaves as such. That doesn't happen then if I keep the mouse on the top half of the monitor while doing this. This part doesn't happen always, but often.

So it feels like something gets thoroughly confused about HiDPI after workspace switches (or firefox become the active window because of that?), while before v92 it just confused after monitors changed events from them waking up after DPMS sleep.

To try to get rid of the problem, I've upgraded from gnome-shell-3.38 to gnome-shell-40.4 and after that didn't help at all, I disabled webrender compositing. This initially seemed to help for a bit, but it just needed some time to start being confused after Firefox restart.
After I started forcing GDK_BACKEND=x11, I'm "free" of these issues.

Comment 1

[Robert Mader [:rmader]]

Thanks for the report! Can you past your about:support here? ("Copy text to clipboard" -> just past it here, bugzilla will offer to make an attachment out of it).

Comment 2

[Mart Raudsepp]

Attachment: about:support

Comment 3

[Mart Raudsepp]

Attachment: about:support (Wayland)

Comment 4

[Mart Raudsepp]

Sorry, had some trouble getting it to restart without the GDK_BACKEND forcing, so the first about:support is still from GDK_BACKEND=x11 and the other from wayland. The problem doesn't start happening immediately, had to suspend and resume to force a DPMS off/on (or some other trigger that this action causes the issue to start manifesting).
I'll try to see if I can get a screen capture from the workspace switch.

Comment 5

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

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

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

Please try latest nightly, how-to is here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.

Comment 7

[Mart Raudsepp]

I am not sure when I can get to testing the nightly, but as an update meanwhile:

The problem persists after upgrading firefox to v93.0 and gnome-shell to 41.0.
I also got a screencast made some time ago that shows this nicely, but unfortunately ended up with a shell overview display including unrelated things I may not share and will need to redo the recording later, if that's the best way to move this forward beyond testing nightly.

Comment 8

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

note: Please run with MOZ_ENABLE_WAYLAND=1 and don't use GDK_BACKEND.

Comment 9

[Mart Raudsepp]

I was only forcing X11 that way to get X11 instead of Wayland, as to not have to restart the browser after each suspend or screen lock due to the bug at hand here. So the note was about accidentally having the first about:support posting not from Wayland due to mistake in removing that workaround.

Comment 10

[Mart Raudsepp]

I couldn't test things sanely for a while due to unrelated issue in https://gitlab.gnome.org/GNOME/mutter/-/issues/1928

But now that I can suspend/resume sanely again, this firefox bug doesn't appear to be a problem anymore, at least so far. Now on firefox-95.0.1 and mutter/gnome-shell 41.2 it has acted sane. Only the first draw ends up freezing it for 3 seconds as it figures things out (8 firefox windows), but afterwards it's fine until next suspend/resume, while before it would keep being a problem on every workspace switch.

Comment 11

[Mart Raudsepp]

I haven't experienced any big issues anymore with gnome 41.2 and firefox-95. Something has fixed it to be good enough.
There is a small stale rendering or something after seeing the firefox window first, but it fixes up once and then never is a problem anymore, unlike before.