The “system information” window is uneffected, because it opens as a tiling window, and not a floating window like the others mentioned.
I got the xwininfo for this window bug too if useful. It appears a refocus is essential for the window to be clickable again. I usually just move Steam to a different desktop, which forces the game properties window to be in focus again, as its the only window on the other desktop.
Properties window:
windowbug.txt
Steam:
steamproperties.txt
I get this on arch (experienced this issue on gnome and kde), non beta steam, very easy to reproduce one is the "move game to another steam library" prompt, this little window gets very stuck, you have to menu dive and 'open' it again, when it'll refocus and is able to be closed/interacted with
https://youtu.be/140qO2AG8Dg here's a video demonstrating the issue. Input is included. It is pretty annoying
Also seeing this with i3. For me at least, after clicking on the main window, only areas of the secondary windows which overlap the main window become unresponsive. And I don't think it's really that anything is unresponsive, it's just that the input is going to the main window. Clicking on a secondary window outside the area which overlaps the main window works, and "fixes" that secondary window. The issue is only observable in i3 if the main window is tiled (which it is by default). If the main window is floating, then clicking on it brings it above the secondary windows and naturally you cannot then click on them. Note that this is also what happens on Windows: when the main window is clicked, it moves in front of secondary windows.
Inspecting i3 logs I can see that i3 gives focus to the secondary windows when they are clicked, but then something (presumably Steam) immediately sends messages to change the focus back to the main window. AFAICT Steam sends a _NET_ACTIVE_WINDOW message and calls XSetInputFocus. i3 can be configured to ignore _NET_ACTIVE_WINDOW, but AIUI input focus is managed by the X server and so i3 has no real say in the matter.
My guess as to what is going on is that Steam is maintaining its own window Z order, and internally dispatching input events based on this. It assumes that when the main window is focused it is brought to the front of the Z order. On (presumably all) tiling window managers, this is not the case -- tiling windows are always kept behind floating windows. This means after clicking on the main window, Steam's idea of the Z order does not match up with the real Z order. When you then click on a secondary window, Steam dispatches this event internally to the main window, because as far as it knows that is what is in front at this position. Steam appears to always forcibly set focus to the window that it thinks has been clicked, even if it already has focus. I think that explains everything I've seen...
Nothing extracted yet.
Your system information
https://gist.github.com/shoober420/1215c40214cf70e1fabb760b5bd2a341
Please describe your issue in as much detail as possible:
After opening a secondary Steam window, whether it be a game properties window, settings window, about steam window, etc...these windows will not be refocusable after focusing back on the main Steam program. So secondary windows that loose focus by focusing on Steam itself will become unfocusable and unresponsive.
I use bspwm, so a remedy to this, is using a key bind to move the main Steam window onto another desktop, therefore leaving the secondary Steam window by itself, forcing a refocus since its the only window on that desktop. This information may help diagnose the issue.
Steps for reproducing this issue: