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

Issue 815385 link

Starred by 3 users
Status: Verified
Owner:
sammiequon@chromium.org
Closed: Apr 2018
Cc:
sammiequon@chromium.org
wuyingbing@chromium.org
█ oka@chromium.org
tbuck...@chromium.org
█ blakeo@chromium.org
yhanada@chromium.org
jdufault@chromium.org
dpa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Ensure PIN entry still works given virtual keyboard changes

Project Member Reported by tbuck...@chromium.org, Feb 24 2018 
I know a lot of logic went into preventing the virtual keyboard from triggering if you enter PIN using the on-screen PIN pad.

Recently they changed the way to programmatically control the virtual keyboard: Issue 642513. It now uses inputmode=none to prevent focus from triggering the virtual keyboard.

Comment 1 by jdufault@chromium.org, Feb 26 2018 

Is this RBS? The only location this affects is md-settings, since lock uses a views-based implementation.

Comment 2 by sammiequon@chromium.org, Feb 27 2018

Labels: -ReleaseBlock-Stable
I couldn't find the changes they made, but i tried inputmode="none" and it works the same as it worked before. Also nothing was broken from previously, so removing the release block stable.

Comment 3 by yhanada@chromium.org, Mar 20 2018

Cc: sammiequon@chromium.org blakeo@chromium.org oka@chromium.org wuyingbing@chromium.org yhanada@chromium.org
 Issue 723293  has been merged into this issue.

Comment 4 by sammiequon@chromium.org, Apr 11 2018

Status: Verified (was: Assigned)
►

Sign in to add a comment