Open Whompithian opened 11 years ago
It does this for me as well.
I've noticed similar behavior when accidentally "dragging" a link. The link may not move or open, but it leaves the client in a state of trying to drag.
This works correctly for me in Unity. Are you all using KDE?
I'm using Gnome Shell, and experiencing this issue.
Do you have focus-follows-mouse set, or anything like that?
Policy: Click to Focus Focus stealing prevention level: Low "Click raises active window" is set.
Those settings seem fine, I'm not sure why it would not repro for me. I'll continue looking at it.
I've still had no luck causing this to happen. Are you clicking with no holding down of the mouse button? You're clicking just on a blank portion of the title bar of the main Steam window? Does it also do this for other windows, such as if you open the Friends window?
This happens with just a single click. It behaves like the mouse button it being held down when it's not. In order to "release" it, I have to click again. I'm using Ubuntu 12.10, Gnome Shell edition. To reproduce this:
Doing this, the issue occurs about half of the time. Let me know if you need any other information, and Thanks!
That works fine for me. It's possible some problem was fixed since our last client release and that's why I'm not seeing it, although I'm not aware of any specific fix for this. We'll be releasing a client update soon and we can see if that makes a difference.
Thanks for the reply. I'll post back after testing with the next client update, and let you know either way.
The new client is out if you want to give it a try.
The issue persists in the new client (Built: Jan 8 2013, at 11:38:03). Grabbing focus on a Steam client window from a non-Steam window by clicking the title bar and releasing the mouse button still results in the window becoming stuck under the cursor. Similarly, if the cursor is over an edge that can be grabbed to resize the window, it will become stuck after a single click when focus was previously on a non-Steam window. The scroll bar and window internals do not exhibit this behavior.
I don't have any issues, so we'll have to continue to try and determine what part of the repro or config we're missing.
The behavior of this issue has changed with the latest release (Built: Jan 14 2013, at 14:57:53). The title bar is not held as reliably. Sometimes, a click on the backgrounded title bar releases immediately, as expected; sometimes it seems to hold the title bar for a split second before release; sometimes a quick click still causes the cursor to grab the title bar. But now, any time I click on the title bar of the client window while maximized, the window is unmaximized.
I just wanted to add that I experienced this same issue -once- with Thunderbird, so it doesn't seem to be unique to Steam. It does still happen fairly often with Steam, whereas it only ever happened that one time with Thunderbird.
What I believe is happening is that the ButtonPress / ButtonRelease are both played to the client before the WM takes the grab trying to respond to the _NET_WM_MOVERESIZE. This is a very interesting race.
We can't solve this at the WM level as _NET_WM_MOVERESIZE has no timestamp field, so we can't filter out the event.
As the WM doesn't send an event to the client when ending a MOVERESIZE drag, it can't track whether we are currently dragging the window, so the only potential way I can see this working is for Steam to always send a _NET_WM_MOVERESIZE_CANCEL on ButtonRelease. This isn't a very good solution, and I'll talk to some more experienced colleagues tomorrow to see if they have any recommendations.
The _NET_WM_MOVERESIZE protocol just seems flat out broken to me.
It seems we can simply QueryPointer when we get a _NET_WM_MOVERESIZE request after taking the grab, and if the button isn't pressed, we'll drop the grab.
For gnome-shell: https://bugzilla.gnome.org/show_bug.cgi?id=699777
Kwin will need a similar bug fix. Unity might already have a similar fix.
Cinnamon 1.8 users are also affected.
This is potentially fixed by https://hg.libsdl.org/SDL/rev/7fde2d881171 and should be resolved with libsdl 2.0.5.
When testing for quirk behavior, use filler space the top of the main window, which is used to click and drag the window around the screen. If no mouse release event is processed, then the window will continue to be dragged with the mouse.
I can confirm that I am no longer affected by this issue with Steam package version 1481318740 (built Dec 9, 2016) and steam-runtime-beta-release_2016-09-02 on KWin 5.7.5. I have not tested with other WM.
The 2017-03-28 steam client is affected by this with MATE 1.12.1 and Cinnamon 3.2.8. Gnome 3.22/wayland and Plasma 5.9 are not affected.
If a Steam client window is backgrounded but visible, then clicking on it will result in a successful mouse click event and bring the window into focus, but the click release will not register. This can be seen by clicking on the title bar of the backgrounded window, which will cause the window to be dragged with the mouse cursor even after the mouse button is released. This is on KDE 4.9.3 with desktop compositing set to OpenGL.