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 3836 - SDL_SetWindowGrab allows clicking outside the window
Summary: SDL_SetWindowGrab allows clicking outside the window
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.5
Hardware: x86 macOS 10.12
: P2 minor
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-20 23:39 UTC by Thierry Crozat
Modified: 2017-10-03 08:48 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thierry Crozat 2017-09-20 23:39:56 UTC
Using SDL_SetWindowGrab(SDL_True) on macOS X 10.12 does not confine the mouse to the window. It can go slightly outside it, allowing to click outside the window and lose focus.

The issue can happen in the corners, especially the bottom left and right corners, but also the top ones (although it is more difficult to reproduce with those). This may be related to the windows having slightly rounded corners on this OS.

This can also happen on the top border, allowing to click on the window title bar (and we can drag it around, although this doesn't work well and the window jumps around the screen - possibly related to bug #719).

After grabbing the mouse I would expect the mouse pointer to stay within the window bounds and to not be able to click outside the window or on its title bar.
Comment 1 Thierry Crozat 2017-09-24 20:22:32 UTC
I should add that this behaviour happens when the window is *not* resizable.

When using SDL_WINDOW_RESIZABLE then I cannot click outside the window and the cursor does not seem to bump/flicker on the borders of the window. I does allow to resize the window, which is a bit strange in my opinion, but might be the expected behaviour.

Somebody also pointed me to bug #2150, which looks like it might be the same bug. So I apologise if you think this bug is a duplicate of bug #2150. I did look for existing bug before opening this one, but the "broken on Linux" bit in the title of bug #2150 made me fail to realise it also mentioned macOS X.
Comment 2 Alex Szpakowski 2017-09-25 12:43:19 UTC
If you don't plan on distributing your app in the Mac App Store you can compile SDL2 with SDL_MAC_NO_SANDBOX defined, which allows SDL to use a better method of making sure the cursor doesn't leave the window.

It's also worth mentioning that SDL_SetRelativeMouseMode should be used when possible instead of SDL_SetWindowGrab, when feasible (e.g. when doing mouse movement tracking for a FPS game). The former avoids most of the issues SetWindowGrab may have.
Comment 3 Alex Szpakowski 2017-09-25 13:20:52 UTC
(In reply to Alex Szpakowski from comment #2)
> If you don't plan on distributing your app in the Mac App Store you can
> compile SDL2 with SDL_MAC_NO_SANDBOX defined, which allows SDL to use a
> better method of making sure the cursor doesn't leave the window.

Specifically, SDL_MAC_NO_SANDBOX defined to 1.
Comment 4 Thierry Crozat 2017-10-02 18:44:19 UTC
Thank you for the suggestions.

I have now updated to SDL 2.0.6, which shows the same behaviour as SDL 2.0.5 when not defining SDL_MAC_NO_SANDBOX. I have also tried with SDL_MAC_NO_SANDBOX defined, and the behaviour is marginally better. It is no longer possible to click on the title bar of the window when the mouse is grabbed and there is less flickering with non-resizable windows when the mouse reaches one of the window edges (although it still happens a bit with the right or bottom edges). It does feel a bit strange to see the system cursor appearing when the mouse reaches one of the edge of the window though, and it is still possible to click outside the window when the mouse is in one of the bottom corners.

Also we are working with point&click games and not FPS, so SDL_SetRelativeMouseMode does not look like it would be very adapted. Although since we draw our own cursor and deliver our own mouse positioning events to the game engines, I guess we could try to use it when we want to grab the mouse and track absolute position of the game cursor in the window from the relative events received.