Mouse: Mouse is always an active pointer #282
Conversation
| bubbles: true, | ||
| cancelable: true, | ||
| buttons: buttons | ||
| }); |
There was a problem hiding this comment.
Oh look, a sane API.
There was a problem hiding this comment.
😠 You're right, we still can't use this.
There was a problem hiding this comment.
The sane API should have given it away. 😈 I'm having the same problem when spitballing jQuery 4.0 event work.
There was a problem hiding this comment.
😭 We'll need to find a way to set the buttons property on IE's mouse event. I think it is only relevant for IE9, since IE10 uses MSPointerEvent and IE11 has native pointer events.
The need for a valid buttons property arises from proper button state checking during capture.
Alternatively, with more and more functional tests, we may be able to skip the four capture related unit tests on IE9 (or in general).
There was a problem hiding this comment.
Oh, well PEP doesn't support IE9 :-)
There was a problem hiding this comment.
Well, that solves it. 😆
|
Looks good. |
|
Sorry, ID of by one. |
This PR tackles #275 by expanding the capture logic to differentiate between active pointers and the active button state.
The
pointermap, which keeps track of active pointers, stores the most recent mouse event, which allows for tracking the state of the mouse more closely.This also reduces the issue of #279, by using the
buttonsproperty of the latest mouse event (likely amousemoveevent) to determine if any mouse buttons are currently pressed. The issue of #279 will remain for browsers without theMouseEvent.buttonsproperty, like Safari.Last but not least, we get to pass three more W3C tests.