sway
sway copied to clipboard
Sometimes firefox and thunderbird are terminated on sway reload
% firefox
Gdk-Message: 15:04:50.996: Lost connection to Wayland compositor.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
zsh: exit 1 firefox
sway 1.6 from debian experimental
Likely because of a Wayland protocol error. Please try Sway master, and try reproducing with WAYLAND_DEBUG=1 in the env.
Hi,
this issue sounds familiar. I could reproduce this with Sway master, although I'd say it took a lot more tries to reproduce than with Debian's 1.6. And this time, only one application was affected. Usually I'm seeing a lot more apps exiting at the same time when reloading.
Please see attached log. I think line 343657 is where it happened.
I can try some more if I find some time on the weekend. As far as I recall, it's not just firefox and thunderbird that are affected but more GUI apps, but maybe it would be good to name the others as well. ;)
Also in the firefox bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1652820
I would bet this is also #6654.
Summary from firefox ticket: Try to comment out "input * ..." lines from config.
I changed:
input * {
xkb_layout "pl"
}
into
input 1133:16419:Logitech_Wireless_Keyboard_PID:4023 {
xkb_layout "pl"
}
input 1:1:AT_Translated_Set_2_keyboard {
xkb_layout "pl"
}
and that fixed my problem
This is, at least in my case, due to https://github.com/swaywm/sway/issues/6654
Happens to me 100% on the sway-reloads. Same for thunderbird
This used to happen to me 100% of reloads, but doesn't anymore.
sway version 1.6.1
Mozilla Firefox 95.0.2
Thunderbird 91.4.1
Any idea what changed on your side? Still an issue for me:
sway version 1.6.1
Mozilla Firefox 95.0.2
Thunderbird 91.4.1
Maybe worth to mention that I have the following in my /etc/environment
MOZ_ENABLE_WAYLAND=1
MOZ_DBUS_REMOTE=1
MOZ_WEBRENDER=1
Not sure if that matters or even if those variables still needed.
Nevermind, after connecting to an external monitor, the issue re-occurs. Without the monitor, reloading works flawlessly, though 🤔 I'm using the Manjaro Sway flavor btw and I don't think the variables are needed (anymore).
Interesting. I am mostly docked and have two external screens attached. Couple of days ago, I restarted sway and kept the firefox window (which was focused at the time of reloading). However, I was not able to reproduce that afterwards.
For me, when the bug occurs, firefox crashes, but also all other windows become unresponsive. On one occasion sway actually straight up crashed out to login manager.
Also in regards to firefox, could the freeze/crash on dragging a tab also be related to the file handle leak? Earlier I had a freeze, and when I killed firefox file-nr dropped by about 6000
Try to comment out "input * ..." lines from config.
Did this, changed the asterisk glob to the identifier of my keyboard. This reduced it from 100% to sometimes for me.
Previously, on all reloads:
firefox
Gdk-Message: 12:01:36.580: Lost connection to Wayland compositor.
Sandbox: Unexpected EOF, op 2 flags 00 path /home/mazunki/.config/xkb
Exiting due to channel error.
Exiting due to channel error.
xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Now, sometimes when reloading:
firefox
Gdk-Message: 12:07:44.167: Error flushing display: Broken pipe
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Sandbox: Unexpected EOF, op 2 flags 00 path /home/mazunki/.config/xkb
xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
I made firefox crash just by sending swaymsg input commands
swaymsg input type:keyboard xkb_layout de
swaymsg input type:touchpad dwt enabled
swaymsg input type:touchpad tap enabled
swaymsg input type:touchpad natural_scroll enabled
swaymsg input type:touchpad middle_emulation enabled
I called this script with repeat until firefox crashed. In my case it was repeat 12.
When I replaced type:keybaord and type:touchpad with '*' it was only repeat 5.
But I think it's also other events that make firefox crash. Even without input lines in config firefox crashes sometimes on swayreload.
sway version 1.8-dev-3b395ed3 Sep 13 2022
For me, this wasn't on reload, but rather whenever I tried to re-order tabs in Firefox by dragging them.
input type:mouse {
pointer_accel -1
}
Changed type:mouse to the specific mouse identifier and the crashing stopped. So different trigger but same resolution. I don't think I've ever had firefox crash on sway reload, but it definitely does not like non-specific input values
I fixed the tab crash issue by disabling tab preview when dragging actually
I ran into a similar issue but it was related to moving Firefox windows from one output to another (not dragging tabs or reloading). The error and general setup was fairly similar though so I will chime in here in case it helps someone else.
For me this appears to be related to having two external outputs + the built in one (eDP1). When I close the laptop lid, eDP1 is disable. If I then reload Sway, eDP1 gets reactivated. In that state, if I move Firefox from one a workspace on one output to a workspace on the other output (not eDP1), it crashes. If I disable eDP1 again (by opening and then closing the lid), I'm able to move Firefox between outputs as usual.
I fixed the tab crash issue by disabling tab preview when dragging actually
@xsrvmy Just in case someone else is trying this, it would be helpful to be a bit more specific. Do you mean setting the preference nglayout.enable_drag_images to false?
Closing this issue as fixed by #7309.
If you have a similar problem, please open a new issue and describe it in detail.
On sway-1.8 (that should include the above fix) I still have this issue of Firefox crashing with this error, however it seems to be related to the outputs, not the inputs.
get_outputs:
Output eDP-1
Current mode: 2560x1600 @ 60.009 Hz
Position: 0,0
Scale factor: 2.000000
Scale filter: nearest
Output HDMI-A-1
Current mode: 1920x1200 @ 59.950 Hz
Position: 1280,0
Scale factor: 1.000000
Scale filter: nearest
To reproduce:
- move the workspace with Firefox to output HDMI-A-1
- disconnect HDMI-A-1 that triggers moving the workspace to eDP-1
- Firefox crashes
End of WAYLAND_DEBUG log:
[3728545.007] [email protected]_id(71)
[3728565.810] -> [email protected]_params(new id zwp_linux_buffer_params_v1@71)
[3728565.874] -> [email protected](fd 39, 0, 0, 7680, 33554432, 274119427)
[3728565.902] -> [email protected](fd 61, 1, 9830400, 2048, 33554432, 274119427)
[3728565.913] -> [email protected]_immed(new id wl_buffer@89, 1920, 1197, 875713089, 0)
[3728565.921] -> [email protected]()
[3728565.944] -> [email protected](wl_buffer@89, 0, 0)
[3728565.964] -> [email protected]_buffer(0, -363, 2560, 1560)
[3728574.562] -> [email protected]()
[3728574.599] -> [email protected](new id wl_callback@84)
[3728574.879] [email protected]_id(71)
[3728574.899] [email protected](wl_surface@47, 2, "Buffer size (1920x1197) is not divisible by scale (2)")
ExceptionHandler::GenerateDump cloned child 1648669
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
The buffer size on HDMI was 1920x1180 (full screen with just a bar on top), with scale=1, the output size of eDP-1 is 1920x800 with scale=2
Firefox 109 should have the fix for this.
The 109.0 firefox updated solved the issue when using regex groups in the input for me. Sadly, it did not solve the same problem ocurring when having multiple keyboards connected at once. Apparently they had different causes.
I fixed the tab crash issue by disabling tab preview when dragging actually
I've been having this issue with Firefox 119 and also found this to be the fix. For anyone else fumbling with this: here is the relevant Firefox documentation for disabling drag previews.