Issue metadata
Sign in to add a comment
|
DevTool's Input.dispatchKeyEvent ShiftLeft rawKeyDown opens chrome://settings/help
Reported by
pawel.gr...@monterail.com,
Oct 24 2017
|
||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36
Steps to reproduce the problem:
1. launch chrome with remote debugging on (default settings from either puppeteer or chromedriver)
2. Send `Input.dispatchKeyEvent` with payload `{ "nativeVirtualKeyCode": 16, "type": "rawKeyDown" }` via devtools protocol.
What is the expected behavior?
Browser should handle received input without loading chrome://settings/help
What went wrong?
Help page is opened immediately after receiving the key event.
Did this work before? Yes
Chrome version: 62.0.3202.62 Channel: stable
OS Version: OS X 10.12.6
Flash Version:
This can be reproduced via multiple ways. I discovered this in Selenium tests when trying to write capital letter into an input field. I quickly narrowed that down to specific comamnds in chromedriver, as shown in the attachment video.
After gathering the chromedriver logs I also managed to reproduce that via puppeteer with following script:
```
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({ headless: false });
const page = await browser.newPage()
const client = page._client
await client.send('Input.dispatchKeyEvent', {
"nativeVirtualKeyCode": 16,
"type": "rawKeyDown",
})
await new Promise(()=>{})
})()
```
,
Oct 25 2017
,
Oct 25 2017
On OSX, keyCode 16 isn't shift. If I recall correctly, it is Y. Sending nativeKeyCode without constructing the rest of the properties is going to give undefined results. If you don't want to trigger browser/OS behavior, it should be safe to just send windowsVirtualKeyCode. See Puppeteer's Input.js for a reference implementation. https://github.com/GoogleChrome/puppeteer/blob/master/lib/Input.js#L43
,
Oct 30 2017
That reduced script is based on chromedriver logs. I deleted some keys, left the minimal set that still triggered the same behaviour. I have deleted them since then and I cannot reproduce it anymore. Currently the same version of chromedriver gives me `windowsVirtualKeyCode` indeed. Weird thing that this behaviour happened on a few machines (all OSX, after the same chrome update), and now it's gone on all of them at the same time. |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Oct 25 2017