1730611 - xfce: Mostly hangs on Linux after screen geometry change (connecting external display)

Status: RESOLVED DUPLICATE of bug 1710400

(Core :: Widget: Gtk, defect)

Description

[jgoerzen]

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

Steps to reproduce:

I begin with Firefox running on the laptop monitor. Several windows are present, some of which are presently mapped to the screen, and others aren't (on other desktops).

Upon connecting an external display, the geometry changes from 1920x1080 to 2560x1440. At that point, Firefox is mostly non-responsive. For instance, clicking on a tab will change the X titlebar, but nothing within Firefox (the display does not switch to the other tab). The URL bar is nonresponsive, etc.

If I start Firefox with the larger display connected, but switch to the smaller one, this does not occur.

I can reproduce this at will -- but NOT with MOZ_LOG=Widget:5 . I can usually with Widget:4.

Actual results:

Firefox becomes unusable until restarted.

Expected results:

Firefox should continue to work normally.

Comment 1

[jgoerzen]

Additional details:

This occurred on both Debian buster and Debian bullseye (Debian 10 and 11). DE is XFCE. Wayland is not used; this is X11.

The first items captured by Widget:4 after the display is connected are:

2021-09-13 22:09:57.412042 UTC - [Parent 34611: Main Thread]: D/Widget GetScreenBounds [7efdccb85000] 0,553 -> 900 x 525, unscaled 0,553 -> 900 x 525
2021-09-13 22:09:57.412103 UTC - [Parent 34611: Main Thread]: D/Widget GetScreenBounds [7efdccb85000] 0,553 -> 900 x 525, unscaled 0,553 -> 900 x 525
2021-09-13 22:09:57.412155 UTC - [Parent 34611: Main Thread]: D/Widget GetScreenBounds [7efdccb85000] 0,553 -> 900 x 525, unscaled 0,553 -> 900 x 525
2021-09-13 22:09:57.412160 UTC - [Parent 34611: Main Thread]: D/Widget nsWindow::GetWidgetScreen() [7efdccb85000]
2021-09-13 22:09:57.412161 UTC - [Parent 34611: Main Thread]: D/Widget   fallback to Gtk code
2021-09-13 22:09:57.412164 UTC - [Parent 34611: Main Thread]: D/Widget nsWindow::GetWidgetScreen() [7efdccb85000]
2021-09-13 22:09:57.412165 UTC - [Parent 34611: Main Thread]: D/Widget   fallback to Gtk code
2021-09-13 22:09:57.412167 UTC - [Parent 34611: Main Thread]: D/Widget nsWindow::GetWidgetScreen() [7efdccb85000]
2021-09-13 22:09:57.412168 UTC - [Parent 34611: Main Thread]: D/Widget   fallback to Gtk code
2021-09-13 22:09:57.412169 UTC - [Parent 34611: Main Thread]: D/Widget nsWindow::GetWidgetScreen() [7efdccb85000]
2021-09-13 22:09:57.412171 UTC - [Parent 34611: Main Thread]: D/Widget   fallback to Gtk code
2021-09-13 22:09:57.412213 UTC - [Parent 34611: Main Thread]: D/Widget GetScreenBounds [7efdccb85000] 0,553 -> 900 x 525, unscaled 0,553 -> 900 x 525

This issue has persisted for quite some time.

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

Comment 3

[Darkspirit]

Please open about:support, click on "Copy text to clipboard" and paste it here. Thanks!

Comment 4

[jgoerzen]

Attachment: about:support detail

Comment 5

[jgoerzen]

After noticing similar symptoms on another laptop, which happened at startup rather than display reconfiguration, I found bug #1710400. That bug is for an issue that happens on startup, rather than one that happens on display reconfiguration, but the symptoms are EXACTLY the same.

Comment 6

[Darkspirit]

Does the same problem occur if you start Firefox with MOZ_X11_EGL=1 environment variable?
$ MOZ_X11_EGL=1 firefox

Comment 7

[jgoerzen]

Nope, no difference with MOZ_X11_EGL=1.

Comment 8

[jgoerzen]

I may have worded that weord. The same problem DOES still occur with MOZ_X11_EGL=1. Sorry if I caused any confusion.

Comment 9

[Darkspirit]

What does $ xrandr --listproviders say? Does it end with "intel" or "modesetting"?

Comment 10

[jgoerzen]

The output is:

Providers: number : 1
Provider 0: id: 0x4b cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 8 associated providers: 0 name:Intel

Based on some comments in bug #1710400, I should also add:

Although this machine is running xfce, it is not running xfwm4. It is running xmonad, a tiling window manager that has nothing to do with any compositors.

I'm not using any custom video settings in xorg.conf, or anywhere else. Everything here is just default. This was the case in both Debian buster and now Debian bullseye (the problem persisted in both).

I have nothing to prove this, but I am somewhat suspicious of a race condition somewhere; it is quite odd to me that using debug level 5 makes the issue go away.

Comment 11

[Darkspirit]

If it's perfectly reproducible, could you try to find a regression range?
$ pip3 install mozregression
$ MOZ_LOG=Widget:5 mozregression --good 2021-02-01 --bad 92 --pref gfx.webrender.all:true -P stdout

Comment 12

[Darkspirit]

Or better run this, it's less confusing, it might not be needed to actually see the log:
$ MOZ_LOG=Widget:5 mozregression --good 2021-02-01 --bad 92 --pref gfx.webrender.all:true

Comment 13

[jgoerzen]

I looked into this some more, based on what's going on in bug #1710400.

I discovered that I had been incorrect when I said the configuration was all standard. This machine had been imaged from another one some time back, and that one had a setting in /etc/X11/xorg.conf.d that forced it to use the Intel driver. I removed that setting, restarted, and the problem went away.

In #1710400, they are proceeding to a discussion of blacklisting the Intel driver for webrender, and I believe that would also solve this issue for those that are still using it for whatever reason.

I suspect that this is the same bug as #1710400, just manifesting itself with different symptoms.

Does this help?

Comment 14

[Darkspirit]

Yes, thanks for checking! :)