Would this explain why I can't actually use the menus? If I open the a menu, and start moving down through it, it closes before I have a chance to select anything.
Nope. An WM_TRANSIENT_FOR on the OR window wouldn't change how we manage the windows.
I can reproduce this easily by changing the focus-mode in gnome3 using gnome-tweak-tool. Setting it to click and steam client is fully functional. Changing it to mouse or sloppy and steam client is unusable.
Found a similar issue #86
This problem affects transparency. With xfwm4, for example, a correctly-hinted menu window would retain the ‘has focus’ transparency setting for the parent window and use the ‘menu‘ transparency setting for the menu window; but, as is, the parent window is rendered with ‘unfocused’ transparency and the menu with ‘has focus’ transparency.
I'd still love to see if fixing this would address #6.
This bug report is growing old although the issue should be easy to fix and is extremely annoying. Any updates?
I'd be happy to try a one-off test build to see if it helps in this situation and/or #6. Seems setting this flag and making sure to have a consistent WM_CLASS is important in this area.
It won't have an effect on #6. The windows are override-redirect, which means the hints on them shouldn't change WM behavior.
Nothing extracted yet.
Steam seems to create menus by simply creating an override-redirect window, as is standard. Unfortunately, they don't set WM_TRANSIENT_FOR (as is recommended by EMWH), so programs that try to group windows by application (WMs like gnome-shell, for instance) fail to see these windows as associated with the main Steam window.
This applies to the main menu bar menu, context menus, and the menus that show up when hovering over "STORE", "LIBRARY", etc.