New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 772507 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Last visit 28 days ago
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Feature



Sign in to add a comment

Headless mode: Remote frontend doesn't properly give focus to a field that's tabbed into.

Reported by samir.ma...@powwowmobile.com, Oct 6 2017

Issue description

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

Steps to reproduce the problem:
1.  From the Terminal, start headless mode using either latest Stable or Chrome Canary:

cd /Applications/Google Chrome Canary.app/Contents/MacOS
./Google\ Chrome\ Canary --disable-gpu --headless --remote-debugging-port=9222 https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_form_submit

2. In regular Chrome, go to http://localhost:9222

3. Click on the "Tryit Editor v3.5" link.

4. Click on the FirstName field, i.e. where it contains the work "Mickey".  The field will get a blue highlight around it to indicate it has focus.  Type in a character to verify that the field has focus.

5. Press the 'tab' key.  The focus and blue highlight will shift to the "Last name:" field, and the word "Mouse" will get auto-selected.

6. Start typing in characters to attempt to change the value from "Mouse" to something else.

Note that the field doesn't change.  You have to click the mouse on the "Last name:" field in order to change it's value.

What is the expected behavior?
The field that seems to have focus - "Last name:" - should be the field that accepts the user input.

What went wrong?
Pressing 'tab' seems to change the field that has the focus and give another field keyboard focus, but it doesn't actually give the new field focus.

Did this work before? No 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
Components: Internals>Headless
Labels: -Type-Bug -Pri-2 Pri-3 Type-Feature
Status: Available (was: Unconfirmed)
Thanks for the detailed bug report!
I was able to reproduce in Linux as well. 

I'm going to reclassify this as a feature request. 
Note the the devtools editor is mainly there for debugging or interacting with the DevTools console, so I'll classify this as not time critical. 

Anyone feel free to grab the bug though!

Owner: lushnikov@chromium.org
Status: Assigned (was: Available)
I think we don't consume Tab and other keystrokes, so the screencast window loses it.

Sign in to add a comment