Closed Bug 1575171 Opened 5 years ago Closed 4 years ago

Frequent freezes on Wayland (with WebRender?)

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1653850

People

(Reporter: nical, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: hang)

I have been getting a lot of freezes recently, often after clicking a link or when switching tabs. There doesn't seem to be heavy CPU activity when the freeze happen and the UI "un-freezes" as soon as I switch between windows using alt-tab, resize the window or similar interaction outdside of the browser.

I've been seeing this on my linux + intel + wayland laptop with webrender, I don't know if it affects other configurations.

Wild guess: we messed something up with the frame throttling and things un-throttle when there's an interaction needs a forced composite.

Blocks: wr-linux
Blocks: 1522903
No longer blocks: 1522903
Blocks: wayland
Priority: -- → P3

I've switched to x11 for a while to see if the issue is happening there as well and so far it looks like it's only on wayland.

Summary: Frequent freezes → Frequent freezes on Wayland (with WebRender?)

Does this bug happen with Kwin/Plasma (only)? If it is so, then this is a known bug that happens with WR and OGL (but not with "Basic") in KDE Plasma.

I don't have a laptop with KDE installed, I'm observing this on a vanilla Fedora + GNOME install.

I observe this as well using sway, on both x86 with amdgpu drivers as well as on arm64 with arm's libmali.so opengl driver.

Unfortunately it only happens a few times a day... often enough to be really annoying but not often enough to troubleshoot easily.

I observe the same with vanilla Arch + GNOME, newest version. This does not happen with the X11 backend.

Do you still see that?
Thanks.

Flags: needinfo?(nical.bugzilla)

I haven't used Wayland in a while (I keep switching to x11 because renderdoc only works properly there). I just switched back to wayland and I'll report back if I run into the issue.

Flags: needinfo?(nical.bugzilla)

So I am still running into this quite frequently. The way it typically goes is I click on a another tab and the window stops updating until either enough time has passed (multiple seconds), or I press alt-tab or resize the window.

During these "freezes" when I move the cursor I can see it change when hoovering areas where there will be text after things go back to normal.

Edit: to be clear this doesn't only happen upon tab switching. It might only happen after I click something although I don't know for sure. I don't remember the window stopping to update halfway through scrolling. I had the profiler running while it happened once and none of the threads involved with JS or gfx or inputs were busy during the freeze.

I'm seeing this on Fedora 32 with GNOME Shell/Mutter 3.36.1

GPU: Mesa Intel(R) HD Graphics 620 (KBL GT2)

This didn't happen on the same system before I upgraded from Fedora 31, which had GNOME 3.34.

It happens very often on complicated web sites like Twitter, whereas I expect I can click around on a Bugzilla all day and not trigger it.

HW_COMPOSITING
blocked by env: Acceleration blocked by platform
OPENGL_COMPOSITING
unavailable by default: Hardware compositing is disabled
GPU_PROCESS
blocked by runtime: Wayland does not work in the GPU process
WEBRENDER
opt-in by default: WebRender is an opt-in feature
WEBRENDER_QUALIFIED
denied by env: Not on allowlist
WEBRENDER_COMPOSITOR
disabled by default: Disabled by default
WEBGPU
disabled by default: Disabled by default

https://gitlab.gnome.org/GNOME/mutter/-/issues/1228

I am also seeing this on a Debian system that I just updated to gnome-shell/mutter 3.36.1. The GNOME developers think this is a problem with Firefox.

I have seen that with Gnome Wayland on Debian Testing. You click on a tab, Firefox often freezes for one second, then it displays the clicked tab. (KDE/X11/Debian Testing/Intel Iris 6100 (Broadwell GT3) is unaffected.)

Blocks: wr-linux-wayland
No longer blocks: wayland
Keywords: hang
OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Blocks: wayland

Is widget.wayland_vsync.enabled enabled?

Is widget.wayland_vsync.enabled enabled?

It isn't enabled.

I updated to Fedora 32 and have been on wayland for a day without running into the issue (could have been also a recent change in nightly).

(In reply to Jan Alexander Steffens [:heftig] from comment #12)

Is widget.wayland_vsync.enabled enabled?

No

This is with Firefox 75 BTW

I'm experiencing freezes on wayland/sway too, specifically on reddit.
i have been able to reproduce this issue in safe mode as well as in a blank profile.

Seeing this issue too with Archlinux up to date, using Firefox 77.0.1.

Still seeing on Fedora 32 with FF 76.0.1

Still happening on Ubuntu 20.04 - Wayland

And FF 77.0.1

Please let me know if you have any idea how to debug this. Firefox is basically unusable on any 'modern' web site which is sadly most of the web these days!

Agree with sam morris here, from the vast majority of issues that #635134 depends on this one seems to be the most important. It really makes Firefox unusable on "modern" website, although I'm neither unsure what is exactly the thing that triggers the freeze, but one site that gives me a lot of headaches is https://hackmd.io. I guess it may be something around scrolling, javascript heavy stuff or something like that. I'm not involved in FF development and don't have a lot of time neither so I'm not sure how to help without investing a lot of time on figuring out how to debug it. With some tips we may be able to help a bit better.

Also, given that #635134 is P2, shouldn't this very important issue be prioritized a bit higher?. Given that Linux Desktop is moving since a while to Wayland and this is really a severe issue if you run on Wayland, I think I'd bump the priority a bit more, at least to P2.

Anyway, besides this request, I wanted to note that I've been using Firefox with Wayland since a while and I need to recognize and thank for all the progress you people have made. I'm Just trying to add a bit of information from my perspective as a user :).

Ladies and Gentlemen,
I would now like to resolve the case so that you can no longer test your patience. The cause of the freezing is the Firefox setting "auto-detect proxy settings for this network" in "Preferences / Connection Settings" which is enabled by default. Switch to "No proxy" and will you never get freezed anymore.
Cheers!

Miss Marple, just tested what you're suggesting on Firefox 78 and it still freezes.

Have just recorded a performance profile https://share.firefox.dev/31zCFwt and I'm leaving it here for Firefox developers to take a look. At the end of that run was when the browser freezes. From what I can see it get's stucked for ~2 seconds in __GI___poll that is triggered from g_io_channel_new_file and up in the stack frame from nsThread::ProcessNextEvent. Hope this is useful.

Hmm, g_io_channel_new_file is used by the Linux gamepad code. Do you have any device /dev/input/js*?

No, I don't have any /dev/input/js* device.

Might it be related to autoscroll? I disabled it yesterday and the freezes seem to have stopped.

I don't think so, I have it turned off and it freezes for me.

https://bugzilla.mozilla.org/show_bug.cgi?id=1653850 seems similar to this issue, at least it is similar to what happens to me.

Just learnt from https://bugzilla.mozilla.org/show_bug.cgi?id=1653850 that pressing super key (windows key) to see activies view on Gnome and then pressing it again to go back to Firefox unhangs Firefox and it's usable again. At least is a trick to not keep waiting for an unhang for a minute or so.

Maybe ... can others confirm if pressing the super key twice unlocks Firefox?.

(In reply to spastorino from comment #30)

Just learnt from https://bugzilla.mozilla.org/show_bug.cgi?id=1653850 that pressing super key (windows key) to see activies view on Gnome and then pressing it again to go back to Firefox unhangs Firefox and it's usable again. At least is a trick to not keep waiting for an unhang for a minute or so.

Maybe ... can others confirm if pressing the super key twice unlocks Firefox?.

Yes, I confirm that trick works for me.

See Also: → 1653850, 1654178

Looks like a dupe of Bug 1653850 so let's track it there.
Thanks.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.