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

Issue 882612 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 867864



Sign in to add a comment

cr-input readonly highlights only on tab backwards

Project Member Reported by steve...@chromium.org, Sep 10

Issue description

Repro:

1. Navigate to a Settings page using 'readonly' input fields
   (Internet > Details > Network or Printing > Printers > Edit printer)
2. Tab to a readonly field.
3. Tab past that field, then shift-tab back to the field.

Observe: Tabbing forward to the field does not select the text, but tabbing backwards to the field does.

Expected: Tabing in either direction should be consistent.

Also: When a field is not 'readonly', tabbing forward to the field does not select the contents, but tabbing backwards does. This should also be consistent. A regular <input> element selects the contents when focused.

 
Shift+tabbing on a cr-input is pretty complicated AFAIR. I suggest consulting with Scott who originally implemented.
I have a fairly simple fix up for review. I will definitely wait for Scott to review it (https://chromium-review.googlesource.com/c/chromium/src/+/1217747).

Labels: M-71
Status: Fixed (was: Started)
Project Member

Comment 4 by bugdroid1@chromium.org, Sep 11

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54a733daaab037e63fe5474be68c6e5877c9c670

commit 54a733daaab037e63fe5474be68c6e5877c9c670
Author: Steven Bennetts <stevenjb@chromium.org>
Date: Tue Sep 11 17:04:35 2018

cr-input: select input element when focused

Currently we select the input element contents when focusing back
to a <cr-input> element with shift-tab, but focusing forward to
a <cr-input> element does not select its contents. This fixes that
behavior to always select the contents to be consistent with the
behavior of <input>.

Bug:  882612 
Change-Id: Iecfbd984928571ca7041133f5621d82fd32f4f35
Reviewed-on: https://chromium-review.googlesource.com/1217747
Reviewed-by: Scott Chen <scottchen@chromium.org>
Commit-Queue: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590357}
[modify] https://crrev.com/54a733daaab037e63fe5474be68c6e5877c9c670/chrome/browser/resources/settings/passwords_and_forms_page/password_edit_dialog.html
[modify] https://crrev.com/54a733daaab037e63fe5474be68c6e5877c9c670/chrome/browser/resources/settings/passwords_and_forms_page/password_edit_dialog.js
[modify] https://crrev.com/54a733daaab037e63fe5474be68c6e5877c9c670/ui/webui/resources/cr_elements/cr_input/cr_input.js

Cc: steve...@chromium.org ajha@chromium.org
 Issue 867864  has been merged into this issue.
This change has caused a regression in FilesApp when focus() is called, see https://bugs.chromium.org/p/chromium/issues/detail?id=914741 The call to select() is causing the regression.

Sign in to add a comment