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

Issue 740787 link

Starred by 1 user
Status: Fixed
Owner: ----
Closed: Jul 2017
Cc:
rtoy@chromium.org
█ brajkumar@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Contenteditable div refocuses on up/down arrow

Project Member Reported by jshoudy@google.com, Jul 11 2017 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1) Go to: https://plnkr.co/edit/yAstVhmznAx7P9G4eKOa?p=preview
2) Click on the content editable div to focus.
3) Click TAB key to bring focus to the button
4) Click the UP or DOWN key and see focus return to the div

What is the expected behavior?
Focus stays on the button. Note: this happens correctly after the first time up/down is clicked.

What went wrong?
Focus jumps to the contenteditable div.

Did this work before? N/A 

Chrome version: 59.0.3071.115  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 26.0 r0

Comment 1 by nyerramilli@chromium.org, Jul 11 2017

Labels: Needs-Triage-M59

Comment 2 by brajkumar@chromium.org, Jul 11 2017

Cc: brajkumar@chromium.org
Labels: Needs-Feedback
Tested this issue on Ubuntu 14.04 using chrome latest stable #59.0.3071.115 by following steps mentioned below.

1. Navigated to https://plnkr.co/edit/yAstVhmznAx7P9G4eKOa?p=preview
2. Clicked on content editable div
3. clicked on tab where the focus travel to the button
4. Pressed up arrow observed the focus moved back to the content editable div
5. Pressed down observed no behavior

Note: This behavior is observed only first time after loading the page

jshoudy@ Could you please confirm is this is the issue you talking about? If yes, I am able to see this issue on chrome older version M45-45.0.2454.0 as well.

Comment 3 by jshoudy@google.com, Jul 11 2017 

Yes this is the problematic behavior I'm seeing.
Project Member

Comment 4 by sheriffbot@chromium.org, Jul 11 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "brajkumar@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
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 11 2017

Labels: Hotlist-Google

Comment 6 by jshoudy@google.com, Jul 11 2017 

I just re-read your steps brajkumar@. One point of clarification:

After step 4 "Pressed up arrow observed the focus moved back to the content editable div" you should:

5) click TAB and see the focus travel to the button for a second time
6) press up arrow again and see that focus does NOT move.

This highlights that the behavior is different in the exact same situation (focus on button and clicking up/down key).

Comment 7 by rtoy@chromium.org, Jul 11 2017

Cc: rtoy@chromium.org
Labels: Needs-Feedback
I tried this with Chrome 60.0.3112.40 (beta) on OSX.  I can't reproduce this issue using the instructions given.  Could this issue be fixed now?

Comment 8 by jshoudy@google.com, Jul 11 2017 

Hmm. I installed 60.0.3112.50 on both Linux and OSX and it appears to not repro there. Maybe it is fixed?

Is there any timeline on when 60.0.3112.40+ will become stable? This is causing a pretty noticeable bug in my project.
Project Member

Comment 9 by sheriffbot@chromium.org, Jul 11 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "rtoy@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

Comment 10 by rtoy@chromium.org, Jul 11 2017

Status: Fixed (was: Unconfirmed)
According to https://www.chromium.org/developers/calendar, Chrome 60 goes stable end of this month.
►

Sign in to add a comment