This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.1
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2013-10-29 20:15:24 +0000, wrote:

When creating a non-fullscreen window in Windows 7 you'll get an SDL_MOUSEBUTTONDOWN event when clicking the title bar if the window doesn't have focus. I.e. if you alt-tab away from the window and then click the title bar to give it focus. This only happens if the window doesn't have focus. You won't get a corresponding SDL_MOUSEBUTTONUP until you click somewhere in the client area.

On 2014-04-29 10:11:17 +0000, Leander wrote:

A manifestation of the same bug, tested with released 2.0.3 DLLs.

I get mouse motion and clicks on my SDL app when opening the start menu!

] <event.type(hex)> . <event.window.event(dec)> W: <event.window.windowID>

00] 0x200 . 11 W:1 <- move mouse pointer out of the window (LEAVE)

01] 0x200 . 13 W:1 <- click/release on calc.exe on the taskbar (FOCUS_LOST)
02] 0x302 . -- W:1 <- (TEXTEDITING) ???

03] 0x200 . 12 W:1 <- click/release on SDL app on the taskbar (FOCUS_GAINED)

04] 0x200 . 13 W:1 <- click/release on start button, menu opens (FOCUS_LOST)
05] 0x302 . -- W:1 <- (TEXTEDITING) ???

06] 0x200 . 12 W:1 <- click/release on start button, menu closes (FOCUS_GAINED)
07] 0x200 . 10 W:1 <- (ENTER) ***
08] 0x400 . -- W:1 <- (MOUSEMOTION) ***
09] 0x401 . -- W:1 <- (MOUSEBUTTONDOWN) ***
10] 0x400 . -- W:1 <- (MOUSEMOTION) ***
11] 0x200 . 11 W:1 <- (LEAVE) ***

*** "spurious" motion and click:
SDL app receives a mouse motion to the bottom y of the window and a mouse button down (and no button up). This causes my SDL app to register a click on its window, which is actually far away from the mouse(sometimes on another screen).
The same behavior happens when giving focus to the SDL app by clicking on its title bar, instead of from the taskbar. In that case the mouse motion is to the top y (i.e. 0).
No actual, physical mouse motion inside the window area is performed after the first event (LEAVE).

??? Not sure this TEXTEDITING events should be sent to the SDL app window after focus lost.

On 2014-10-13 04:00:48 +0000, JH wrote:

I am also getting this bug on Windows 7. Clicking the title bar of my application when it is not focused generates a SDL_MOUSEBUTTONDOWN event. Ironically, it generates this event when the mouse button is released.

If I press and hold for a second or so before releasing, both down and up events are generated at the moment of release. (This is still weird, but much less problematic.)

This bug is frustrating because the application then behaves as if the user is clicking and dragging all over the place.

Leander's explanation seems like it might be a separate bug.

On 2014-11-16 21:19:22 +0000, Charles Ambrye wrote:

This also occurs on Windows 8. When clicking the titlebar an SDL_MOUSEBUTTONDOWN event will occur, with no corresponding SDL_MOUSEBUTTONUP event (unless you hold down your mouse for a few moments - a standard click won't do). This will cause the SDL state machine to assume there is a mouse button down, and your next SDL_MOUSEBUTTONDOWN event will be missed. Is there a way I can simulate an SDL_MOUSEBUTTONUP event so that I can work around this issue?

On 2015-10-10 00:47:41 +0000, harry wrote:

This is based on looking at SDL 2.0.3 and specifically in src/video/windows/SDL_windowsevents.c.

The WM_ACTIVATE event is triggered when taking focus via clicking the title bar which calls WIN_CheckAsyncMouseRelease(). This updates the SDL mouse state and adds a DOWN event. Upon releasing the mouse in the non-client area, the corresponding UP event is either not sent or not processed.

If the left mouse button is held briefly, then on release a WM_EXITSIZEMOVE occurs. This event also calls WIN_CheckAsyncMouseRelease() and subsequently generates the UP event.

This bug is also triggered with the WM_EXITMENULOOP event, which does not depend on gaining focus. For example, right-clicking the title bar to open the move menu and then clicking in the non-client area to dismiss the menu.

Changing WIN_CheckAsyncMouseRelease() to only process release events fixes the issue and seems like it may have been the intent given the name of the function.