I have a weird issue on Fedora 42 where sometimes (seemingly when I am switching between windows), a window will decide to go semi-transparent (I’d estimate it has around 20% opacity, so mostly transparent) and stay that way. I can switch between other windows, minimize it and restore it, but nothing helps except closing the window and reopening it, which is obviously pretty annoying.
Worse, when one window decides to go, others tend to as well. For example, I just had a PDF viewer window go semi transparent when I switched away from it, and so did two VS Code instances on the same workspace, but not some VS Code instances on another workspace.
I have an AMD GPU and journalctl didn’t show anything obviously useful to me. Is this phenomenon a known thing? It’s hard to search for anything related to window transparency and find bugs rather than features.
Did you activate Kwin’s “Translucency” effect for inactive windows? I have observed a bug with that where, when I minimized an inactive (therefore translucent) window, it would simply be drawn again as a ghost window, with no way to interact with it. Restoring the minimized window would then bring the actual application window back as a second copy. Once I reset the setting back to its off state the issue went away.
The issue seemed very sporadic because I only rarely clicked to minimize an unfocussed window so it took me a while to pinpoint the cause of it. Once I did, it was 100% reproducible. Your description sounds different but I wanted to make sure that you weren’t seeing this bug.
Thanks, but I don’t think that’s it. I haven’t heard of Kwin, but it sounds like it’s a KDE thing and this is Gnome. Besides, the behavior doesn’t sound quite like what I’m experiencing. I’m pretty sure mine are still interactive, but just very difficult to see due to low opacity. I’ll have to check that more thoroughly next time though because I don’t have the issue right now.
Yes, Kwin is KDE’s window manager/compositor. And I could have sworn that your post was tagged kde but it’s clearly gnome. Sorry for the red herring, I guess I wasn’t fully awake yet.
I’m also on GNOME, but haven’t experienced such a behavior.
Do you have any GNOME Shell extensions installed and enabled? If so, maybe one of those could be the culprit. You could disable them, then start enabling them one by one, until you experience the issue again.
You can rule out user configuration settings by creating a new “test dummy” user to see if the issue is from something at the system level. If the problem affects your the test dummy user, you should post hardware details (run inxi -Fzxx in a terminal and post the output as pre-formatted, web searchable, text using the </> button). Ths may allow someone with similar hardware to reproduce the issue, or may get the attention of users on other distros who have the same issue – either will be helpful.
I have some more info captured with screen recording. It doesn’t seem like I can upload the recordings here, so I threw them up on Gofile here. If there’s a better place for me to put them, please let me know.
There are two recordings:
Me interacting with a window that is stuck in mostly transparent state
Me applying the workaround (by hovering over the window preview)
I tried recording the actual triggering of the problem but it’s proving difficult. I think it’s when I switch workspace partway through a window preview being rendered, but I could be wrong.
NOTE: the recordings will be auto-archived if not accessed within 10 days.
I watched your videos, so just a few questions about that.
When you minimize the text editor and then open it by clicking the text editor icon, does it open translucent or opaque? Or is it only when text editor (or any other app is closed) and you open it for the first time that they appear translucent?
Once it gets into the translucent state, it stays that way until I unstick it with the workaround. I can literally do anything: switch to other apps, other workspaces, minimize and maximize it (per the recording). Nothing will make it opaque again except that workaround I show.
No, but as I mentioned it’s proving very difficult to actually trigger the problem in the first place. It seems to happen when I’m in the flow and moving quickly. I think the strongest hypothesis I have is that it happens when switching workspaces with a window preview render in progress, but it’s hard to actually get that to happen reliably.
So you have dash to panel installed yes?
This extension introduces several opacity manipulations as a feature to its operation.
For example it has a window peeking feature on hover that renders a preview window with tweakable opacity settings.
And historically it looks like these opacity tweaks around its window previews have resulted in transparent windows in the past.. There are several historic closed issues around this sort of thing.
I can’t be sure, but I suspect this is a race condition inside dash-to-panel involving how opacity is being applied. If you disable dash-to-panel entirely I suspect you can’t make this happen ever. Once you’ve isolated it to dash-to-panel operation, there might be an opacity feature of dash-to-panel you can disable as a specific workaround to avoid running into the race condition that I suspect. All the opacity stuff that dash-to-panel does by default appears to be configurable to taste on my quick investigation.