You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had some problems trying to test the pan gestures using Protractor/WebDriver. I couldn't perform any sequence of actions simulating the mouse events, because HammerJS recognized only the first event from the sequence and immediately ended the gesture recognition, calling "panend".
It turns out that this unusual behavior has ben caused by the ev.which property check in the mouse events input handler (https://github.com/hammerjs/hammer.js/blob/master/src/input/mouse.js#L37). The property is marked as "non-standard" on MDN. WebDriver doesn't add this property to simulated events, what makes the testing with Protractor impossible.
I would suggest changing the ev.which to ev.button, which is a standard feature and is used four lines above.
(also, ftr asking because I think we should be consistent, either both lines should use which or both should use button, just want to confirm we aren't shooting ourselves in the foot elsewhere, because (surprise) mobile browsers have mouse events too).
@runspired Unfortunately I have not found such support matrix yet. I had an opportunity to perform some experiments on the latest Chrome on Android 5.0 and 6.0 with a USB mouse attached. Both MouseEvent.which and MouseEvent.button properties are defined, but their values depend on the pressing time rather than the number of the button that was pressed:
button: 0, which: 1 - for left, right or middle click
button: 2, which: 3 - for left, right or middle long press
Regarding mobile mouse events, as far as I know they will not work anyway due to #812.
This misalignment there is odd and seems likely do be a source of buggy behavior if not accounted for, @arschmitz is there a spec you can point me to on that?
To further the discussion, there's also a distinction between ev.button and ev.buttons.
one caveat with button seems that the output is 0, irrespective if the left button is pressed or not, while buttons has 0: no button, 1: left, 2: right and 4: middle.
further, some browsers seem to support a meaningful which for mouse events, while others do so with buttons.
i think we should introduce a small fallback mechanism, where we first check for one type and if not found we fallback on other as one of them is bound to be supported.
Activity
runspired commentedon Jul 12, 2016
@Paul167 Can you point me to documentation on support matrix for
MouseEvent.button?MDN shows near universal (IE9+) desktop support for this property, but is lacking information for mobile browsers. https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/button
Meanwhile, for "non standard"
MouseEvent.which, support is shown to be universal.https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/which
runspired commentedon Jul 12, 2016
(also, ftr asking because I think we should be consistent, either both lines should use
whichor both should usebutton, just want to confirm we aren't shooting ourselves in the foot elsewhere, because (surprise) mobile browsers have mouse events too).Paul167 commentedon Aug 3, 2016
@runspired Unfortunately I have not found such support matrix yet. I had an opportunity to perform some experiments on the latest Chrome on Android 5.0 and 6.0 with a USB mouse attached. Both
MouseEvent.whichandMouseEvent.buttonproperties are defined, but their values depend on the pressing time rather than the number of the button that was pressed:button: 0,which: 1- for left, right or middle clickbutton: 2,which: 3- for left, right or middle long pressRegarding mobile mouse events, as far as I know they will not work anyway due to #812.
runspired commentedon Aug 18, 2016
This misalignment there is odd and seems likely do be a source of buggy behavior if not accounted for, @arschmitz is there a spec you can point me to on that?
arschmitz commentedon Aug 18, 2016
@runspired
https://www.w3.org/TR/uievents/#interface-mouseevent for the button property
which is non standard and not speced but mdn article here https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/which
arjunkathuria commentedon Aug 29, 2016
To further the discussion, there's also a distinction between
ev.buttonandev.buttons.one caveat with
buttonseems that the output is 0, irrespective if the left button is pressed or not, whilebuttonshas0: no button,1: left,2: rightand4: middle.further, some browsers seem to support a meaningful
whichfor mouse events, while others do so withbuttons.i think we should introduce a small fallback mechanism, where we first check for one type and if not found we fallback on other as one of them is bound to be supported.