We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2842 - MOUSEBUTTONDOWN on the SDL Window Title bar doesn't register BUTTONMOUSEUP. App believe button is still held down until next click on canvas.
Summary: MOUSEBUTTONDOWN on the SDL Window Title bar doesn't register BUTTONMOUSEUP. ...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.3
Hardware: All Windows 7
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.4
Depends on:
Blocks:
 
Reported: 2015-01-12 05:52 UTC by M-Griffin
Modified: 2015-05-31 04:52 UTC (History)
4 users (show)

See Also:

Attachments
Proof of Concept source file attached. (3.47 KB, text/plain)
2015-01-12 05:52 UTC, M-Griffin 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description M-Griffin 2015-01-12 05:52:01 UTC 
Created attachment 1990 [details]
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.
Comment 1 M-Griffin 2015-01-14 06:01:58 UTC 


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.
Comment 2 Ryan C. Gordon 2015-02-19 06:32:16 UTC 
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!
Comment 3 Paulo Marques 2015-03-05 14:34:21 UTC 
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.
Comment 4 Paulo Marques 2015-03-05 16:38:58 UTC 
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.
Comment 5 M-Griffin 2015-03-11 20:25:49 UTC 
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.
Comment 6 Paulo Marques 2015-03-12 14:28:39 UTC 
For MacOSX I've already posted a patch (sort of) on the SDL mailing list that fixes it for me.
Comment 7 Ryan C. Gordon 2015-04-07 04:57:57 UTC 
(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.
Comment 8 Joshua Bodine 2015-05-27 08:37:25 UTC 
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.
Comment 9 Paulo Marques 2015-05-27 15:00:01 UTC 
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...
Comment 10 Sam Lantinga 2015-05-28 15:46:27 UTC 
The Mac OS X bug was fixed in bug 2396
Comment 11 Sam Lantinga 2015-05-28 16:00:52 UTC 
The Windows bug is fixed for 2.0.4.

Thanks!
Comment 12 Joshua Bodine 2015-05-29 05:39:09 UTC 
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.
Comment 13 Ryan C. Gordon 2015-05-29 19:47:18 UTC 
(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.
Comment 14 Ryan C. Gordon 2015-05-31 04:17:21 UTC 
I can't reproduce this with testsprite2 on Mac OS X 10.9.5. Should I move up to 10.10 and retest?

--ryan.
Comment 15 Ryan C. Gordon 2015-05-31 04:19:18 UTC 
(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.
Comment 16 Ryan C. Gordon 2015-05-31 04:42:45 UTC 
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.
Comment 17 Ryan C. Gordon 2015-05-31 04:52:01 UTC 
(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.