sway: Chromium-based browsers sometimes don't resize properly and/or become unresponsive.
- Sway Version: 1.8.1
- Kernel: 6.6.13
- Fedora 39 Sway Spin running on Framework Ryzen 7 7840U, no discrete graphics
- Latest versions of Chrome and Brave respectively via native installations from the respective repos.
- Wayland ozone backend enabled
I’ll lead with: while there’s clearly an issue somewhere, I’m unsure if it’s with Sway specifically versus Wayland, wlroots, etc… my hope is that, at minimum, someone can point me in the right direction!
In short, I first highlighted this issue on Reddit to see if anyone in the community had experienced what I was describing and/or if I was crazy or missing something obvious given that I was new to Wayland + Sway (coming from i3 on X11).
Other folks chimed in and said they’ve been experiencing the same issue, but I’m still unsure of the root cause and/or where to focus my time and effort in terms of identifying the culprit.
I’ll defer to the Reddit thread for a more thorough description of the issue, along with my experience and that of others – happy to provide additional context or be helpful to the extent that I can!
About this issue
- Original URL
- State: open
- Created 5 months ago
- Reactions: 4
- Comments: 31
fwiw, I built sway from head (
sway --versionreports “sway version 1.10-dev-dcb142bf (Apr 3 2024, branch ‘master’)”) against head wlroots (meson.build has version as “0.18.0-dev”).Since then, I have not had this problem anymore. My current chrome version reports today as “123.0.6312.105”, but it’s been working reliably for the last week or so (instead of the freezes >10x a day that I was experiencing previously). Occasionally, an individual Chrome window might freeze in a similar way that it used to in the past, but it would always automatically redraw and recover itself somehow within 1 or 2 seconds.
@hungyao unfortunately the chrome source is used for other projects as well e.g. electron, brave etc., and they don’t necessarily keep up with the latest. I’ve been using Hyprland for 3 weeks now and haven’t seen the problem, so there is definitely something Sway could do to address this. I’d prefer to use Sway but I’m always in Chrome for Google Meet calls and other work related apps can’t afford to disrupt my work.
So far the same problem does not appear to happen in Hyprland. I’m going to daily drive Hyprland for a few days and see if it happens again.
I ran with
chromium --enable-logging=stderrfrom the command line and was able to reproduce it. Unfortunately nothing special in the logs.I realized I’m able to reproduce it within a minute by flipping my kvm back and forth between my two machines very quickly. Will try on Hyprland and see if the same issue occurs…
I’ve got it in the broken state right now, where one window is no longer rendering, and the other is fine. If anyone is paying attention, is there anything I can do to debug?
I had a brutal day with it today. Was on a video con in chromium with multiple directors, thinking everything was fine as I could hear them talking, then they called my name, and I frantically tried to unmute, realizing the browser stopped rendering. Had to exit and reload and apologize.
A couple interesting tidbits:
I had another chromium window that was open, and it was operating without issue even though the other had stopped updating.
I have a KVM and switched to another laptop during the meeting, and when I switched back the rendering was stopped in one of the windows. I’m also running kanshi to update screen setup on output changes so it could be related to change of outputs and scaling, or to kanshi itself.
Forgot to mention, if there is any testing or other information I can provide, I would be more than happy to help! I would also be very down to try and help submit a patch to address this but am not really sure where to start with this one ^^.
+1 experiencing the same issue on a Framework 13" Laptop with 12th Gen Intel graphics
I also cannot conclude that this is sway or wl-roots related but just wanted to add another data point. I have been experiencing this issue for quite a while now on Brave but never with Firefox. In my case the content of the browser window freezes but when I click on the frozen tab bar I do notice the window title updating in
waybar. No content in the container refreshes and nor can I close the window using thekillbinding insway.It appears that the issue is somewhat window size related as I notice this almost exclusively when the window is the only one on the workspace. The issue also seems to be more prevalent plugged into a 4k external monitor, oftentimes when I create a new Brave window on an empty workspace it launches straight away in this “frozen” state. I have found I can usually remedy this by opening a terminal window first and then opening Brave so it opens up as a split and then this issue doesn’t present itself. However, once I eventually close the padding terminal, after sometime the large browser window can again freeze (integrated and external display). I was unable to find an issue in the Brave repo, but glad to see I am not alone here ^^.
Same version of Sway and Kernel, NixOS stable 23.11.
Seeing it on two Thinkpads with Intel graphics, and a Dell XPS with a GTX 1050, so it does not appear to be GPU specific.
I believe I only started seeing it after switching to Wayland rendering for Chromium and Brave browsers.
I’ve seen similar behavior with Signal Desktop and VLC, both in Wayland mode, though they just crashed rather than staying alive with rendering being stuck. Appears to have something to do with being tiled or full screen. I never see this behavior with floating windows. Could be a different issue though as I never keep the browsers floating.