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.

Sam, are we ever supposed to get legitimate LeaveNotify events in X11 fullscreen? I feel like there's some scenario where we can't ignore these (multi-monitor? The user alt-tabbing out of the fullscreen game?)

--ryan.

Created attachment 2794 [details]
the fix

Ryan, please find the attached new patch
that does not have the event filtering
code. I put the code that ignores fake
enter events (that are the consequence
of the fake leave events) into an app
itself, so please apply the obvious fix.

I know that we were getting mouse button events in fullscreen mode. I'm cautious about applying this because we may get double mouse events.

Ryan, can you do a regression test across your various window managers and the various windowed / grabbed / fullscreen modes?

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.6.

This means we're in the final stretch for an official SDL 2.0.6 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.6 release, and generally be organized about what we're aiming to ship. After some debate, we might just remove this tag again and deal with it for a later release.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

(In reply to Sam Lantinga from comment #3)
> I know that we were getting mouse button events in fullscreen mode. I'm
> cautious about applying this because we may get double mouse events.

It's not clear to me why this patch is needed. From the XGrabPointer docs:

"If owner_events is True and if a generated pointer event would normally be reported to this client, it is reported as usual. Otherwise, the event is reported with respect to the grab_window and is reported only if selected by event_mask. For either value of owner_events, unreported events are discarded."

(owner_events is True for us, so it should be ignoring the mask.)

I also don't understand why this isn't a massive widespread problem if this is the fix. Stas, is there anything strange about your computer's setup? Is it a really bleeding edge version of the X11 server that maybe changed something?

--ryan.

(Also, you only need XInput2 for relative mouse mode, I think, which does not require you to manually grab the mouse pointer to the window; maybe that's the combination that triggers this bug?)

I did more tests.
It appears the bug only happens if there is
another window on the screen that has "always
on top" property. For me it is xawtv - it is
always opened in a screen corner. Closing
xawtv or removing "always on top" property
from it makes the problem to go away.
Plus, it doesn't appear like the buttons are
not delivered at all. It appears that instead
the button presses are delivered on some mouse
positions, but not delivered when you move the
mouse to other part of the window... So this is
really weird and is likely somewhere deep in the
Xorg.
Maybe somehow it happens that the cursor is
actually above the xawtv window, but, because
my app uses grab, it is not visible there, and
in that case the events are not delivered to
my app?
But with my patch the button events are
always delivered flawlessly, it seems.

Hmm, and that indeed seems to explain my problem:
if the mask is set properly and my app uses
grab, then, even if the mouse is above some
other window, the events would still be delivered
to the grabbing app, which is what actually wanted
because my app uses relative mouse mode, so it
doesn't know the pointer can cross some other window
(my app draws the pointer itself).
So my current theory is that my patch only enforces
the mouse grab, which otherwise can be tricked by
some other window preventing the button events
delivery (but motion events are still delivered
via xinput2, which makes it all look very obscure).

Ok, I tried this out and it doesn't seem to do any harm, so if it helps your setup to have it, we might as well push the patch.

It's in revision control now: https://hg.libsdl.org/SDL/rev/749cb40916f2

Thanks!

--ryan.