New issue
Advanced search Search tips

Issue 791709 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

dispatchMouseEvent with button option 'right' is not working

Reported by jin.c...@powwowmobile.com, Dec 4 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
1. Use the following CLI to start chrome at this mouseEvent test site:
chrome-canary --headless --disabled-gpu --remote-debugging-port=9222 http://unixpapa.com/js/testmouse.html
2. Go to browser at localhost:9222 and click through to the linked page.
2. Right click the "click here to test" link or the "or here" image.

Or

1. Run chrome in headless mode and traverse to http://unixpapa.com/js/testmouse.html with screencast.
2. Use the Input domain's dispatchMouseEvent twice with the following options back to back:
let option1 = {x: 100, y: 100, type 'mousePressed', clickCount: 1, button: 'right'};
let option2 = {x: 100, y: 100, type 'mouseReleased', clickCount: 1, button: 'right'};

What is the expected behavior?
The textarea should print out:

mousedown   which=3 button=2 buttons=2
contextmenu which=3 button=2 buttons=2
mouseup     which=3 button=2 buttons=0

What went wrong?
When the button option is set to 'right', the event does not dispatch. It works for the option 'left' though.

Did this work before? N/A 

Chrome version: 62.0.3202.94  Channel: stable
OS Version: OS X 10.13.1
Flash Version:
 
Components: Internals>Headless
Labels: Needs-Triage-M62 ProjHeadless

Comment 2 by dats@chromium.org, Dec 6 2017

Labels: Needs-Feedback
Tried it on a latest build and it worked for me. After issuing:
>>> Input.dispatchMouseEvent({x: 200, y: 100, type: 'mousePressed', clickCount: 1, button: 'right'})
{ result: {} }
>>> Input.dispatchMouseEvent({x: 200, y: 100, type: 'mouseReleased', clickCount: 1, button: 'right'})
{ result: {} }

I've found this in the DOM:
'mousedown   which=3 button=2 buttons=2\ncontextmenu which=3 button=2 buttons=2\nmouseup     which=3 button=2 buttons=0\n'

If there was such problem it has been fixed already. Please recheck.
Could this be a OS specific version of headless chrome? I am using the Mac version and I just tested it with 'Version 65.0.3285.0 (Official Build) canary (64-bit)' and I was not able to reproduce it.
Project Member

Comment 4 by sheriffbot@chromium.org, Dec 6 2017

Cc: dats@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "dats@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: einbinder@chromium.org
Status: Assigned (was: Unconfirmed)
Screencast mode assumes you are testing a mobile device, and so turns on mobile emulation. There is a conversion going on from mouse -> touch -> mouse events which drops the right click, but that is working as intended.
Ok, that makes sense. This actually lead me to the  Emulation.setEmitTouchEventsForMouse API which allows me to set this translation off so things are showing as it should now. Thanks for the clarification!
Sounds like there's nothing to fix here on the Chrome side?
Nope. Thanks for all the help!
Status: WontFix (was: Assigned)

Sign in to add a comment