New issue
Advanced search Search tips

Issue 658499 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Should GestureLongPress fire auxclick?

Project Member Reported by rbyers@chromium.org, Oct 22 2016

Issue description

If you cancel contextmenu you get an auxclick from right click.  But for long press, you get only mousedown and contextmenu.  Shouldn't this be consistent?

Test eg. Http://rbyers.net/eventTest.html - enable the "preventDefault contextmenu" option and long press the link.

From: https://twitter.com/fugueish/status/789666628355043328

 

Comment 1 by rbyers@chromium.org, Oct 22 2016

Cc: dtapu...@chromium.org
BTW, it's not obvious to me (or maybe I've forgotten) when exactly long press generates mouse events and when it doesn't. Only on links?  

 I know text selection makes this tricky (certainly don't want selecting text to look like right-clicking). I wonder how much interop we have here...

Comment 2 by rbyers@chromium.org, Oct 22 2016

Description: Show this description
Cc: -nzolghadr@chromium.org
Labels: Hotlist-Input-Dev
Owner: nzolghadr@chromium.org
Status: Assigned (was: Untriaged)
Labels: auxclick
Status: Started (was: Assigned)
rbyers@ even if we call preventDefault on contextmenu longpress doesn't fire mouseup at all. Should it? if we don't fire mouseup we cannot sent auxclick either.

Comment 6 by rbyers@chromium.org, Oct 26 2016

Yep, I think gesturelongpress should either be behaving like a real mouse in terms of the events that get fired, or not fire mouse* events at all (which IIRC may be the case on Safari?).
Cc: mustaq@chromium.org
Here is the scenario.
1. Press one finger down
2. Wait a few seconds
3. Wait a little longer and release

FireFox on Android fires
1. Nothing
2. contextmenu event button=2 and buttons=2
3. Nothing

Edge fires
1. pointerdown
2. Nothing
3. pointerup and then contextmenu (with button=2 and buttons=0)

Chrome on Android fires:
1. pointerdown
2. mousedown and then contextmenu (with button=0 and buttons=0)
3. pointerup

The button(s) for contextmenu event is set to 0 after  issue 579564 . Which means we assumed finger is not a pointing device per spec link in that issue. Is it not?


However here is Chrome on Windows:
1. pointerdown
2. mousedown and then contextmenu (with button=0 and buttons=0)
3. pointerup (and now real contextmenu opens!!!)



One thing I'm thinking is that we send auxclick(click) for pointerdown followed up by pointerup for button !=0 (==0) events. At least that was the generalized idea I guess. But since this is a gesture event we should decide what click/auxclick compat mouse events we would like to have here just like tap. I'm not sure what the best sequence is though particularly what Chrome does in Win vs Android. Should we all of a sudden send contextmenu event (and open it) while the finger is on the screen for all the platforms? In that case if contextmenu is preventDefaulted. Should we send anything at all while the finger is still on the screen (i.e. before step 3) or should we wait until the finger is released?
btw, here is the page I tested with:
https://jsbin.com/tamurox/edit?html,output

I thought about this a little more and I suggest not sending auxclick in these scenarios as the pointerup is happening way after the long press gesture. Also when long press gesture happens there is no pointerup/mouseup. So it might be weird to send an auxclick. WDYT?

Comment 9 by mustaq@chromium.org, Oct 31 2016

Not sending an auxclick seems cleaner to me. In general, I am slightly biased towards the second model Rick suggested in #6: there should be no mouse* events at all here. I tried to get rid of the mousedowns in the past, but had to bring it back because of a focusing-wo-cursor issue on a text area.

Since the mousedowns are hacky, this shouldn't trigger more follow-up events unless absolutely necessary IMO---it would make the real fix (fixing text area focus) harder.

The mousedowns with button=0 is caused by a slip in the same CL of mine, should be fixed (but contextmenu button=0 is correct).

I put up the fix for only changing the button(s) fields. But I did it for both contextmenu and mousedown. This way we match FireFox and we haven't violated the spec in the sense that we consider fingers like pointing devices and we set the button(s) field just like touch pointer events. So it kind of makes sense to me to do it this way.
Let me know if you feel strongly about setting button(s)=0 for contextmenu event.
Also we are moving forward with not sending auxclick for this gesture but keeping mousedown for that focus problem Mustaq mentioned in #9.
Project Member

Comment 11 by bugdroid1@chromium.org, Nov 1 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/53040d2c8ff415e4db439943247e86767a01e7be

commit 53040d2c8ff415e4db439943247e86767a01e7be
Author: nzolghadr <nzolghadr@chromium.org>
Date: Tue Nov 01 20:27:17 2016

Set right button for mousedown/contextmenu of long press gesture

This CL will set the right button for the mousedown
and contextmenu events.

BUG= 658499 

Review-Url: https://codereview.chromium.org/2446333002
Cr-Commit-Position: refs/heads/master@{#429091}

[modify] https://crrev.com/53040d2c8ff415e4db439943247e86767a01e7be/third_party/WebKit/LayoutTests/fast/events/mouse-event-buttons-attribute-expected.txt
[modify] https://crrev.com/53040d2c8ff415e4db439943247e86767a01e7be/third_party/WebKit/Source/core/input/GestureManager.cpp

Status: Fixed (was: Started)

Sign in to add a comment