dfreedm
commented
9 years ago I believe that this is a bug in Firefox on Linux (GTK).
The spec states that the value of buttons should be the currently held mouse buttons, which suggests that mouseup.buttons should exclude the button that was released because it is no longer currently held.
The Windows and Mac versions of Firefox, and IE 11 agree on this, and only the linux version of Firefox sends the previously held button value on mouseup.
It looks like this inconsistency has been brought up by @RByers on the Chrome implementation of buttons currently being reviewed: https://codereview.chromium.org/727593003/#msg16. It seems most likely that the Chrome implementation of buttons will be consistent with IE and Windows and Mac Firefox.
Therefore, I'll work around the Linux behavior of Firefox by forcing it to go through the buttons state machine inside the mouse recognizer.
@kaosat-dev, thanks for the PR, but I think solving this issue by detecting Firefox is more appropriate.
I am not getting "tap" events on firefox 33.0.2 on Linux. I believe I have the latest version of polymer-gestures. I know there was a recent issue about this and that work was done to fix that problem. I traced my problem to line 65 in tap.js.
tap = (e.buttons ^ 1) && (downState.buttons & 1);
This checks that button 1 is up on the up event. This is not the case and the tap event is blocked. I found this doc online about the buttons:
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent.buttons
Gecko notes Gecko supports the buttons attribute on Windows, Linux (GTK), and Mac with the following restrictions: ... On Linux (GTK), the 4th button and the 5th button are not supported. In addition, a mouseup event always has the releasing button information in this attribute value. ...