Steam client window does not register mouse release when grabbing focus

[Whompithian]

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.

Processor Information:
    Vendor:  GenuineIntel
    Speed: 3199 Mhz
    4 logical processors
    4 physical processors
    HyperThreading:  Unsupported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Supported
    SSE42:  Unsupported

Network Information:
    Network Speed:  

Operating System Version:
    Linux (64 bit)
    Kernel Name:  Linux
    Kernel Version:  3.5.7-gentoo
    X Server vendor:  The X.Org Foundation
    X Server release:  11300000

Video Card:
    Driver:  NVIDIA Corporation GeForce GTX 465/PCIe/SSE2

    Driver Version:  4.3.0 NVIDIA 310.19
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x10de
    DeviceID:  0x6c4
    Number of Monitors:  1
    Number of Video Cards Not Detected
    Primary Display Resolution:  1920 x 1200
    Desktop Resolution: 1920 x 1200
    Primary Display Size: 20.39" x 12.76"  (24.02" diag)
                                            51.8cm x 32.4cm  (61.0cm diag)
    Primary Bus: PCI Express 16x
    Primary VRAM: 1023 MB
    Supported MSAA Modes:  2x 4x 8x 16x 

Sound card:
    Audio device: Analog Devices AD1988B

Memory:
    RAM:  7976 Mb

Miscellaneous:
    UI Language:  English
    LANG:  en_US.utf8
    Microphone:  Not set
    Total Hard Disk Space Available:  64508 Mb
    Largest Free Hard Disk Block:  28615 Mb

Installed software:

Recent Failure Reports:
    Thu Dec 20 02:30:21 2012 GMT: file ''/tmp/dumps/crash_20121219183021_1.dmp'', upload yes: ''CrashID=bp-bf597dab-2c7a-4630-88dd->e8f6c2121219''

[benmoran56]

It does this for me as well.

[MrSchism]

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.

[gdrewb-valve]

This works correctly for me in Unity. Are you all using KDE?

[benmoran56]

I'm using Gnome Shell, and experiencing this issue.

[gdrewb-valve]

Do you have focus-follows-mouse set, or anything like that?

[Whompithian]

Policy: Click to Focus Focus stealing prevention level: Low "Click raises active window" is set.

[gdrewb-valve]

Those settings seem fine, I'm not sure why it would not repro for me. I'll continue looking at it.

[gdrewb-valve]

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?

[benmoran56]

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:

1. Open the Steam client.
2. Open another application (I'm usually using Firefox).
3. Give focus to the other application, so that the application is covering part of the Steam client.
4. Click on the Steam client near the menu area

Doing this, the issue occurs about half of the time. Let me know if you need any other information, and Thanks!

[gdrewb-valve]

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.

[benmoran56]

Thanks for the reply. I'll post back after testing with the next client update, and let you know either way.

[gdrewb-valve]

The new client is out if you want to give it a try.

[Whompithian]

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.

[gdrewb-valve]

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.

[Whompithian]

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.

[benmoran56]

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.

[magcius]

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.

[magcius]

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.

[Tele42]

Cinnamon 1.8 users are also affected.

[Tele42]

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.

[Whompithian]

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.

[kisak-valve]

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.