This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Proof of Concept source file attached. (main.cpp, text/plain, 2015-01-12 05:52:01 +0000, 3554 bytes)

Reported in version: 2.0.3
Reported for operating system, platform: Windows 7, All

Comments on the original bug report:

On 2015-01-12 05:52:01 +0000, M-Griffin wrote:

Created attachment 1990
Proof of Concept source file attached.

I posted some extensive information in the SDL forums for the issue.
https://forums.libsdl.org/viewtopic.php?t=10958

I've confirmed with another developer who has noticed the same issue.
To summarize: If you are in window mode (not fullscreen)

1. Click and release the mouse button in the app a few times over the canvas.

2. Click on the desktop to switch program focus.

3. Click on you SDL program's window title bar without moving and release.

Once the click on the windows title bar is done, it registers a MOUSEBUTTONDOWN event with event.button.button set to right or left. The MOUSEBUTTONUP is never registered for the release of the button when clicking on the title bar.

This leaves the event state to believe that the mouse button is still being held down. Future checks on event.button.button will then continue to register a mouse button being held down.

I believe the issue can be resolved if a MOUSEBUTTONUP is registered on release from a click on the title bar of the window and the event.button.button is reset to not register a button being held down.

This appears to only be an issues when focus is switched from the SDL app to another app or window, then back to the SDL app with a click on the title bar.

On 2015-01-14 06:01:58 +0000, M-Griffin wrote:

In the MOUSEMOTION Event I also tried switching from:

if (event.button.button == SDL_BUTTON_LEFT)

to:

if (event.motion.state & SDL_BUTTON_LMASK)

This results in no difference. The Left mouse button is still registered as always active until you click another mouse button on the canvas.

On 2015-02-19 06:32:16 +0000, Ryan C. Gordon wrote:

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry
if you got a lot of email from this. This is to help me sort through some bugs
in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4,
though!

On 2015-03-05 14:34:21 +0000, Paulo Marques wrote:

I can confirm that the same thing happens in MacOSX. In MacOSX you don't even have to switch applications, just pressing the title bar while using the application, triggers the problem.

In Linux, however, there is no problem. I've checked and XWindows doesn't send a ButtonPress event when the user clicks the title bar.

So maybe this is a generic problem (not platform dependent), it just doesn't show up in Linux because the lower layers don't even inform SDL of the mouse clicks on the title bar.

On 2015-03-05 16:38:58 +0000, Paulo Marques wrote:

I did some more tests with MacOSX and this is what I found out:

• MouseDown (in SDL_cocoawindow.m) is called even when the mouse is in the title bar. Mouse Down doesn't check the mouse po and calls SDL_SendMouseButton to report the event

• MouseUp (in SDL_cocoawindow.m) is not called when the mouse is in the title bar

• Cocoa_HandleMouseEvent (in SDL_cocoamouse.m) is called in both these cases, but the events (NSLeftMouseDown, NSLeftMouseUp, etc.) are ignored

So, maybe this is not a generic problem, and maybe this actually changed in the latest MacOSX versions (I'm using Yosemite 10.10.2).

One solution is to check in MouseDown if the event actually happened inside the window and ignore it if it happens outside the client area.

Another solution is to use Cocoa_HandleMouseEvent for button events, but that seems to be a more drastic change.

In any case, solving this for MacOSX doesn't seem to help Windows at all, which was the original bug report.

On 2015-03-11 20:25:49 +0000, M-Griffin wrote:

The problem is even If you try to ignore the clicks by checking the canvas coordinates, Y = 0 on title bar clicks, and not negative when on the title bar.

However, the fact remains that the button state is still in a constant BUTTON DOWN event because no release registers a BUTTON UP.

Until you click and release the button again on the canvas, the first mouse click and hold is ignored until after its release. So you end up having to click twice to get the functionality working again.

On 2015-03-12 14:28:39 +0000, Paulo Marques wrote:

For MacOSX I've already posted a patch (sort of) on the SDL mailing list that fixes it for me.

On 2015-04-07 04:57:57 +0000, Ryan C. Gordon wrote:

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.

On 2015-05-27 08:37:25 +0000, Joshua Bodine wrote:

I am also experiencing this same issue:

When there is a non-fullscreen window on Mac OS X, clicking on the title bar of the window generates a SDL_MouseButtonEvent for a button down the first time you click on it (if your last click was somewhere inside the window). When you release the mouse button, no corresponding button up event is generated. Once you have clicked on the title bar of the window once, subsequent clicks on the title bar do not generate this same button down event again, until you click back in the window and then on the title bar again. Additionally, once you click on the title bar, your first click back inside the window does not generate a button down event, although when you release the button, a button up event is generated and it then functions like normal.

My operating system is Mac OS X 10.10.3. This bug was seen using current mercurial code as of 05/27/15.

Also, it appears that bug report number 2195 is related.

On 2015-05-27 15:00:01 +0000, Paulo Marques wrote:

If you search the SDL mailing list, there is a post from me with a suggestion to change the code that fixes this issue. The post subject is "[SDL] MacOSX 10.10 Yosemite, mouse down on the window title bar but no mouse up [SOLVED]"

It seems it didn't get any attention, though...

On 2015-05-28 15:46:27 +0000, Sam Lantinga wrote:

The Mac OS X bug was fixed in bug 2396

On 2015-05-28 16:00:52 +0000, Sam Lantinga wrote:

The Windows bug is fixed for 2.0.4.

Thanks!

On 2015-05-29 05:39:09 +0000, Joshua Bodine wrote:

I'm still experiencing the issue in the latest SDL 2.0 code in mercurial on Mac OS X 10.10.3. Bug 2396 appears to have to do with relative mouse mode.

Paulo Marques mentioned in his mailing list post that when you copy SDL_cocoamouse.m:374-380 into the Cocoa_WindowListener::mouseDown function in SDL_cocoawindow.m, the problem goes away. I just verified that this is still the case with the current code. Whether this is a proper solution or not, I do not know.

On 2015-05-29 19:47:18 +0000, Ryan C. Gordon wrote:

(In reply to Joshua Bodine from comment # 12)

I'm still experiencing the issue in the latest SDL 2.0 code in mercurial on
Mac OS X 10.10.3. Bug 2396 appears to have to do with relative mouse mode.

Reopening bug and reassigning to me.

--ryan.

On 2015-05-31 04:17:21 +0000, Ryan C. Gordon wrote:

I can't reproduce this with testsprite2 on Mac OS X 10.9.5. Should I move up to 10.10 and retest?

--ryan.

On 2015-05-31 04:19:18 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 14)

I can't reproduce this with testsprite2 on Mac OS X 10.9.5.

(That is to say, I get an SDL_WINDOWEVENT_LEAVE when I move the cursor to the titlebar, and clicking on the titlebar generates neither mouse up or mouse down events. Going to try an older version from Mercurial.)

--ryan.

On 2015-05-31 04:42:45 +0000, Ryan C. Gordon wrote:

Just tried this on my wife's 10.10 MacBook and it's 100% reproducible, so I guess it's a regression/conflict with 10.10 specifically. Fixing.

--ryan.

On 2015-05-31 04:52:01 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 16)

Just tried this on my wife's 10.10 MacBook and it's 100% reproducible, so I
guess it's a regression/conflict with 10.10 specifically. Fixing.

Okay, this should be fixed now on 10.10. https://hg.libsdl.org/SDL/rev/525f13ccf27f

Hopefully closing this bug for the final time! :)

--ryan.