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.

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!

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.

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.

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.

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

(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.

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.

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...

The Mac OS X bug was fixed in bug 2396

The Windows bug is fixed for 2.0.4.

Thanks!

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.

(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.

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

--ryan.

(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.

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.

(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.