sway: Firefox constantly crashes using native wayland

Sway Version:

1.8.1

Debug Log:

Configuration File:

Description:

Install sway, in my case I am using NixOS, disable xwayland via configuration, and launch Firefox from the terminal with the command firefox. Use it a couple of minutes or hours and wait until it randomly closes showing the following console output:

Gdk-Message: Lost connection to Wayland compositor

I figured out that it happens more often when you constantly use the web developer tools. Here is a video of me following the above described procedure and crashing Firefox after two minutes: https://github.com/swaywm/sway/assets/123883702/97d6a9ea-6ad9-48b7-8166-e096fb303951

Unfortunately I cannot find a more specific crash log, there is nothing in about:crash and the debug mode also shows no further information.

About this issue

Original URL
State: open
Created a year ago
Reactions: 3
Comments: 24 (2 by maintainers)

Most upvoted comments

That’s probably FF bug 1743144 which is a somewhat fundamental wayland design issue possibly exacerbated by GTK forcefully terminating the process instead of giving it a chance to handle the error. Some compositors implement workarounds, but wlroots maintainers don’t want to implement those since they consider this a bug that needs to be fixed somewhere else. It’s not clear if any project considers it their responsibility to fix this issue.

It’s especially common if you have a high polling rate mouse.

A possible workaround without patching any project is to write a wrapper program that invokes firefox and then looks up the the file descriptor of the child which represents the wayland connection between firefox and sway and adjusting the buffer sizes on the socket, this could probably be done in a few lines of python or rust.

the8472 on Jul 23, 2023

If you’re feeling adventurous/desperate you can try https://github.com/the8472/weyland-p5000

Note that this is proof-of-concept level code that may well be worse than the issue it’s supposed to work around. I’m not even dog-fooding it since i3 is still my daily driver.

the8472 on Nov 29, 2023

Note that the fix for this is https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188.

emersion on Dec 8, 2023

I tried @the8472’s proxy, which made Firefox more stable, but I can still easily cause a crash by simply opening a lot of tabs very quickly, or selecting and trying to move many tabs at the same time.

lonjil on Dec 10, 2023

That’s probably FF bug 1743144 which is a somewhat fundamental wayland design issue possibly exacerbated by GTK forcefully terminating the process instead of giving it a chance to handle the error. Some compositors implement workarounds, but wlroots maintainers don’t want to implement those since they consider this a bug that needs to be fixed somewhere else. It’s not clear if any project considers it their responsibility to fix this issue.

It’s especially common if you have a high polling rate mouse.

A possible workaround without patching any project is to write a wrapper program that invokes firefox and then looks up the the file descriptor of the child which represents the wayland connection between firefox and sway and adjusting the buffer sizes on the socket, this could probably be done in a few lines of python or rust.

This is kinda insane to be honest

Cloudef on Dec 8, 2023