Skip to content
This repository has been archived by the owner on Mar 13, 2018. It is now read-only.

firefox buttons still a problem with tap #77

Closed
RTFaught opened this issue Nov 5, 2014 · 1 comment
Closed

firefox buttons still a problem with tap #77

RTFaught opened this issue Nov 5, 2014 · 1 comment

Comments

@RTFaught
Copy link

RTFaught commented Nov 5, 2014

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.
...

@RTFaught RTFaught changed the title firefox buttons still a problem with tab firefox buttons still a problem with tap Nov 5, 2014
kaosat-dev added a commit to kaosat-dev/polymer-gestures that referenced this issue Nov 19, 2014
@dfreedm
Copy link
Contributor

dfreedm commented Nov 19, 2014

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants