New issue
Advanced search Search tips

Issue 778036 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



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(()=>{})
})()
```
 
chromedriver_opens_help.mp4
1.7 MB View Download
Labels: Needs-Triage-M62
Owner: einbinder@chromium.org
Status: Assigned (was: Unconfirmed)
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
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