1691738 - Firefox developer edition freezes on Wayland/sway when visiting whereby.com

Status: RESOLVED DUPLICATE of bug 1754789

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

Description

[Tassilo Horn]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15

Steps to reproduce:

I'm using firefox developer edition 86.0b7 on Arch Linux and the Sway window manager. Firefox runs with MOZ_ENABLE_WAYLAND=1. Arch follows the new beta builds very closely.

Since a few days, sometimes my firefox "freezes" in the sense that the window doesn't seem to get repainted anymore. However, when I click on another tab, I can at least see the window title changing. But I still see the other tab.

When that happens, CPU usage also increases. The only cure seems to be restarting firefox (which I have to do with kill from the command line).

I've also tried just letting it sit in that state for 10 minutes in order to check if it would recover. When coming back to the computer, the system was completely unresponsive, the reason being that its 16GB RAM have been filled up by firefox processes.

While this issue happened mostly at work with our internal JIRA and intranet sites, I've been able to reproduce the issue on my private notebook, too, simply by visiting https://whereby.com and scrolling there or resizing the firefox window.

I've used the mozregression PIP package to find out the first build where the issue is present. Here is what it says:

5:39.07 INFO: Downloading build from: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JPad-z8jQPqhfC23eNOSHA/runs/0/artifacts/public%2Fbuild%2Ftarget.tar.bz2
5:39.48 INFO: Running mozilla-beta build built on 2021-02-06 20:29:47.605000, revision db88aae5
5:49.26 INFO: Launching /tmp/tmpz1r3txct/firefox/firefox
5:49.26 INFO: Application command: /tmp/tmpz1r3txct/firefox/firefox -profile /tmp/tmp4ygua7n2.mozrunner
5:49.27 INFO: application_buildid: 20210206185709
5:49.27 INFO: application_changeset: db88aae50f12be5b39d06cec3ccc3eed998a1c6a
5:49.27 INFO: application_name: Firefox
5:49.27 INFO: application_repository: https://hg.mozilla.org/releases/mozilla-beta
5:49.27 INFO: application_version: 86.0
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
7:20.27 INFO: Narrowed integration regression window from [77be67aa, 748c0d50] (3 builds) to [77be67aa, db88aae5] (2 builds) (~1 steps left)
7:20.27 INFO: No more integration revisions, bisection finished.
7:20.27 INFO: Last good revision: 77be67aa9ff4a9c93441ceeb3bdb7fc91d8f86f1
7:20.27 INFO: First bad revision: db88aae50f12be5b39d06cec3ccc3eed998a1c6a
7:20.27 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=77be67aa9ff4a9c93441ceeb3bdb7fc91d8f86f1&tochange=db88aae50f12be5b39d06cec3ccc3eed998a1c6a

Actual results:

Firefox froze when visiting https://whereby.com in the sense that it stopped being repainted. CPU utilization increased to about 150%-200% (4-core system) and eventually RAM utilization increased indefinitely.

Expected results:

The site should be rendered and firefox should not freeze.

Comment 1

[Tassilo Horn]

Hm, the above first bad revision and last good revision cannot be correct when looking at the changes. So most probably I just didn't try hard enough to trigger the issue and marked some bad version(s) as good. Now I've tried mozregression again and tested each build by visiting whereby.com and then repeatedly reloading while constantly scrolling up and down using two-finger dragging on the touchpad. This is the result this time:

4:03.05 INFO: Using local file: /home/horn/.mozilla/mozregression/persist/f74039c739be-shippable--mozilla-beta--target.tar.bz2
4:03.05 INFO: Running mozilla-beta build built on 2021-02-04 20:24:08.079000, revision f74039c7
4:03.91 WARNING: Skipping build fd81ea0a07c4: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-beta.shippable.revision.fd81ea0a07c49d0389b0244002cd9ea6806bd8d3.firefox.linux64-opt'
4:14.20 INFO: Launching /tmp/tmpf3o07vjf/firefox/firefox
4:14.20 INFO: Application command: /tmp/tmpf3o07vjf/firefox/firefox -profile /tmp/tmp5xf78jt8.mozrunner
4:14.21 INFO: application_buildid: 20210204185843
4:14.21 INFO: application_changeset: f74039c739be9b75fbbf739155fedd870ea8d940
4:14.21 INFO: application_name: Firefox
4:14.21 INFO: application_repository: https://hg.mozilla.org/releases/mozilla-beta
4:14.21 INFO: application_version: 86.0
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
5:21.34 INFO: Narrowed integration regression window from [957dc6bd, c6425910] (4 builds) to [f74039c7, c6425910] (2 builds) (~1 steps left)
5:21.34 INFO: No more integration revisions, bisection finished.
5:21.34 INFO: Last good revision: f74039c739be9b75fbbf739155fedd870ea8d940
5:21.34 INFO: First bad revision: c6425910a3fd1b1f4a985baa630610b2c877b009
5:21.34 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=f74039c739be9b75fbbf739155fedd870ea8d940&tochange=c6425910a3fd1b1f4a985baa630610b2c877b009

Again, it's possible that I've marked some bad version as good just because the repro is not too reliable.

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

[Tassilo Horn]

FWIW, I cannot reproduce the issue with Gnome on Wayland. However, I can easily reproduce it on sway/wlroots even though I've tried using git versions of those up to 21 days old. I suffer from this issue for at most a week, so this seems to be sway/wlroots-only but at the same time being triggered only by some very recent firefox developer edition update, i.e., a recent 86 beta release.

Comment 4

[Tassilo Horn]

(In reply to Tassilo Horn from comment #1)

5:21.34 INFO: Last good revision: f74039c739be9b75fbbf739155fedd870ea8d940
5:21.34 INFO: First bad revision: c6425910a3fd1b1f4a985baa630610b2c877b009
5:21.34 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=f74039c739be9b75fbbf739155fedd870ea8d940&tochange=c6425910a3fd1b1f4a985baa630610b2c877b009

Again, it's possible that I've marked some bad version as good just because the repro is not too reliable.

I've performed the mozregression test once again with a lot of thoroughness, and time and came to the very same result.

Comment 5

[javiertury]

I face a similar problem and using MOZ_WEBRENDER=0 makes the problem go away. Does it work for you too?

Comment 6

[Tassilo Horn]

Apparently, I'm not able to reproduce the problem with whereby.com using Firefox Developer Edition 87.0b9 (64-bit). But it still happened to me several times in the last few days on some company intranet sites, preferably ones which open pop-up dialog windows which first show up as tiled window for a fraction of a second before being some rule kicks in and makes them floating. Too bad, whereby.com happened to trigger that bug quite easily when I reported it...