sway
sway copied to clipboard
swaywm
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!
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.
+1 experiencing the same issue on a Framework 13" Laptop with 12th Gen Intel graphics
- sway version 1.8.1
- Arch Linux with Kernel 6.7.0-arch3-1
- Brave Browser 120.1.61.120 | Chromium 121.0.6167.85 Arch Linux
- Wayland ozone backend enabled
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 the kill binding in sway.
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 ^^.
Maybe just a coincidence but I'm also running on an external 4k monitor as well.
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 ^^.
I was unable to find an issue in the Brave repo, but glad to see I am not alone here ^^.
Appreciate the additional data points friends, I was starting to think I was crazy! :sweat_smile:
Wanted to especially +1 the context @qasimwarraich provided, that pretty closely mirrors my own experience! Also echoing suspicions that an external display (see below) increases prevalence, although I'd need to A/B against sans external displays (which I rarely do unless I'm traveling) to confirm for sure.
This is causing me a lot of headache in my day-to-day workflow, I'd love to get to the bottom of it! Just this morning I ended up having to restart my machine while having a lot of windows+tabs (Brave) open and, upon restarting the browser, roughly 1/3 of the windows entered this state immediately on start.
The most frustrating part is that they can't be killed/reclaimed! Even using the browser's native Task Manager to nuke the tabs doesn't eliminate or otherwise change the frozen/unresponsive windows.
The issue also seems to be more prevalent plugged into a 4k external monitor
Maybe just a coincidence but I'm also running on an external 4k monitor as well.
I'd need to test to confirm, but I was seeing this issue originally on my laptop's internal eDPI display (2256x1504, 3:2).
Additionally, I use a 1.5 scale factor for that internal display.
I then plug in this laptop to a non-4K (3840x1600 21:9 widescreen, older & low PPI) display with a 1.0 scale factor. It's hard to tell if it happens with more frequency, although I could believe that being the case anecdotally.
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.
I also work along side 3 other Wayland users. The all run NixOS (different hardware) with one running GNOME and the other two using hyprland. They have not experienced this issue with chromium browsers. Just to add some more information.
I also work along side 3 other Wayland users. The all run NixOS (different hardware) with one running GNOME and the other two using hyprland. They have not experienced this issue with chromium browsers. Just to add some more information.
The plot thickens! It'd actually been on my todo list to give Hyprland a test drive and see if I could reproduce the issue on that WM, but I halfway suspected I'd see the same thing.
Maybe this is more closely related to Sway than I originally hypothesized?! :thinking:
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.
For what it's worth, I'm also using Kanshi, although I'm 90% sure I was observing this issue completely outside of having started to use that bin!
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'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?
Wish I could be more helpful! This issue has been driving me bananas but I'm unsure of the best way to debug.
I've shrunk the window down by making it floating and dragging it smaller, and you can see the border overlapping the browser which doesn't actually change size. I can only move or resize within the small border, but as I move the window the entire locked up browser moves.
swaymsg -t get_tree also returns rect and window_rect to the expected size but geometry to the stuck full-window size.
Probably not the same issue, but there's this:
https://bugs.chromium.org/p/chromium/issues/detail?id=987821
I have had this problem with any chrome-based browser with the ozone platform set to wayland including Microsoft Edge since I started using sway back to 1.5 or 1.6. I am currently on Sway 1.9RC2 with Vulkan rendering, and it still happens. For me, the issue mostly happens when opening a PWA. I use Firefox personally, but I have to use Microsoft Edge for some work stuff. I set the ozone platform to X11 to prevent this issue from occurring.
I ran with chromium --enable-logging=stderr from 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...
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.
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.
Keep us posted!
In addition to this being a pretty good insight into the overall source of the issue, while I'd prefer to stay on Sway, this has been disruptive enough to my day-to-day work/life (without a lot of time/bandwidth/know-how to debug!) that I might possibly consider switching WMs, even if temporarily :sweat_smile:
So after a few days of Hyprland usage it looks like it doesn't have the problem. I'm almost certain that it's a problem with both chromium and sway, and not just one or the other at this point though - I've got two chromium windows open and also see it get corrupted when I change monitor config, but it's still being rendered, and floating/unfloating in Hyprland fixes the issue, unlike Sway.
I'm not sure if this is the same as everyone else here, but this is what I'm experiencing:
Laptop with an internal display at 1.5 scaling, two external monitors at 1.0 scaling. I'm not sure if this is relevant or not. I have the ozone platform flag set to Wayland.
Sway 1.8.1 Brave 1.62.156 (Chromium 121.0.6167.139) Manjaro Sway Edition Kernel 6.7 (definitely happened on 6.6 and I'm almost positive it happened on 6.5)
If I start brave on external display it will become immediately unresponsive. I can close it and reopen it and it'll almost always immediately be unresponsive. However, if I open another window on that display before opening brave, brave will work correctly almost indefinitely. E.g., open a terminal, then open brave, close the terminal and brave seems to work fine.
I think it always works fine if I start it on the internal display. Occasionally freezing if I move it to an external display.
Very similar setup, almost certainly related to external displays and probably scaling too.
I am running on a desktop with 3 identical 1920x1200 monitors, so it has nothing to do with external displays or scaling in my case.
I would consider an external display a monitor connected to a laptop vs the internal display which would be the laptop screen. They often will have different resolutions and scale factors.
Continuing to have issues with this, although, maybe it's just placebo, but I'm finding myself more and more in the state where the window title changes/responds but no re-rendering happens.
At least, in that case, I'm able to CTRL+W repeatedly and eventually get the window to go away.
For what it's worth, to the degree that it could be important, since originally posting the issue, I've upgraded to kernel 6.7.4 (from 6.6.x).
Here's an example recently, and the steps I took:
- I restarted my computer and, upon restarting the browser, had all of my pre-existing windows re-open.
- Accordingly, I threw many/most of them into different workspaces based on context.
- See screenshot 1: two out of the four (only three pictured, didn't capture the entire 21:9 widescreen) windows sent to this workspace entered a buggy state. However, because they still responded to user input (I observed the window title updating), I was able to at least close all of the tabs.
- See screenshot 2: ironically, in closing some of the buggy windows, one of the ones that was previously fine entered a buggy state (the one with the Framework ethernet expansion card, different slice of the overall 21:9 viewport pictured).
Haven't noticed this issue over the last week 🥳. Not sure what exactly happened. Can anyone else confirm?
Haven't noticed this issue over the last week 🥳. Not sure what exactly happened. Can anyone else confirm?
I've actually been having more issues ironically, just recently in fact!
As for what's different, I just switched my external monitor from 3840x1600 (Dell 38" U3818DW) to a 5K2K monitor with a lot more pixels (Dell 40" U4025QW) and I suspect that's the primary driver.
However, I've fairly recently updated my system and all related dependencies, including browser (Brave) version and kernel (now 6.7.9), although I don't suspect those would have made the problem any worse.
That said, I've yet to encounter a scenario in recent memory where a window became entirely unresponsive ("bricked", can't even force kill) -- rather, it enters a state similar to the screenshot I posted above where the window title does update and a CTRL-W keypress to close a tab does work, it's just not reflected visually.
I've gotten into a habit of continually repeating this process until I've killed the last tab in a window, the window subsequently closes, and then I use the CTRL+SHIFT+T keybinding repeatedly to open recently closed tabs (effectively reconstructing the window state).
It's annoying, but it's at least manageable!
Can be releated to [1]?
[1] https://chromium.googlesource.com/chromium/src.git/+/c3469b5b6680ec614be0806e39945bb8f580b19f
fwiw, I built sway from head (sway --version reports "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.
Although this probably comes as no surprise (Chromium/Electron iirc), I've started seeing this problem intermittently using Discord, installed via Flatpak.
More often than not, it occurs when spawning the system file picker to upload an image/file.