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.

Created attachment 3161 [details]
Program to reproduce bug

(I know there are some similar bugs on here already, but this one seems
different, and arguably more serious.)

On Windows 10, when a window gains mouse focus, SDL can send mouse events
with out-of-date (x,y) position and button-state fields (containing data
from the last time the window had mouse focus, which was possibly a long
time before).

The attached program can be used to demonstrate the effect.

To conduct the test:
 1. Drag the mouse from a point inside to a point outside of the
    "Mouse Event Bug Test" window.
 2. Release the mouse button.
 3. Move the mouse back into the window, re-entering the window at a point
    different from where it exited.

For example (I can get this trace by bringing the mouse pointer back into the
window via its top edge):

   event type 1024 : mouse motion to (52,0), button state is 1
   event queue empty; mouse is at (52,0) button state 1

   event type 1024 : mouse motion to (52,0), button state is 1
   event type 512 : window event type 11 (lost mouse focus)
   event queue empty; mouse is at (52,0) button state 1

   event type 512 : window event type 10 (gained mouse focus)
 * event type 1024 : mouse motion to (225,0), button state is 1
   event type 1026 : mouse button up at (225,0), button state is 0
   event queue empty; mouse is at (225,0) button state 0

The mouse-motion event on the line marked with a * has an out-of-date
button-state field.


It can also be the position that is out of date.
For example (I can get this trace by bringing the mouse pointer back into the
window via its bottom edge):

   event type 1024 : mouse motion to (66,59), button state is 1
   event queue empty; mouse is at (66,59) button state 1

   event type 1024 : mouse motion to (66,59), button state is 1
   event type 512 : window event type 11 (lost mouse focus)
   event queue empty; mouse is at (66,59) button state 1

** event type 1026 : mouse button up at (66,59), button state is 0
   event type 512 : window event type 10 (gained mouse focus)
** event type 1024 : mouse motion to (66,59), button state is 0
   event queue empty; mouse is at (66,59) button state 0

   event type 1024 : mouse motion to (253,59), button state is 0
   event type 512 : window event type 11 (lost mouse focus)
   event queue empty; mouse is at (253,59) button state 0

   event type 512 : window event type 10 (gained mouse focus)
   event type 1024 : mouse motion to (253,59), button state is 0
   event queue empty; mouse is at (253,59) button state 0

The events on the lines marked with ** have out-of-date (x,y) fields.
In a way this example is even worse than the first one: when the window gains
mouse focus, a clutch of 3 events are sent, but none of them manages to
update the mouse position correctly (as we confirm by calling
SDL_GetMouseState() after all 3 events have been processed and the queue has
become empty again). The mouse position is finally updated some time later,
when the (physical hardware) mouse has moved again.

It seems that when SDL sends a window-gained-mouse-focus event, it doesn't
update its internal mouse-state variables, as surely it should?

I've also tried this with SDL 2.0.2 on Ubuntu 14.04, but on this Linux setup
the events sent are different, and do not exhibit this bug.