Jacob, it looks like the input field is getting focused for keyboard. Could you have a look at that?

Also raising priority if the bug as main use case for PIN is tablet and it means that it doesn't work well for tablet :) 

+tbuckley FYI and to make sure he agrees on prio.

+sammiequon who's been working on PIN Settings

Yes, agreed on prioritization. Though we're having trouble repro'ing -- we can enter a PIN using the virtual keyboard by either longpressing the top row of keys or switching to the number entry. We could not get the numbers to appear in the suggestion row as in the screenshot.

Using version 60.0.3102.0

Note that when this was built, there was no way to prevent the virtual keyboard from triggering when an input was focused and so some complicated workarounds were needed. Now that that's supported (see Issue 642513), we should hopefully be able to simplify the logic.

Any update?

Managed to repro on my scarlett (though that is on M59 version). Still not reproduce-able on Kevin. It seems maybe the VK needs to be in like the picture above with 123.... on a seperate row above; on Kevin it is 1q 2w 3e etc. 

oka/yhanada - How do you alter the VK to have the numbers on a seperate row? 

I can repro this on my caroline, eve and scarlet (they are on M61). The layout with separated numerical row is loaded when focusing on an input field whose type is set to "password". I guess that the keyboard fails to see the input type of the PIN field for somewhat reason on your kevin.

+wuyingbing: Please correct me if I'm wrong.

Hmmm I got my hands on a caroline and eve whose password boxes would open the keyboard with the separate numerical row, but after updating chrome (to debug) this is no longer the case. And it is for all password boxes not just PIN one.
 
wuyingbing - Has this changed recently?

yhanada - I am able to reproduce this now -- it only shows up on the official build VK (the ones with the numbers on a seperate row). My debugging shows me that none of these keys on this VK emit keyCodes (the numbers at least). Is this something you or the VK team could look at?

Thank you for testing. I'll take a look at why key events aren't fired.

By the way, I thought that the goal of this issue is letting the VK not show when opening this view. Is this right?

Re #9 - Yes, not showing the VK is preferred and being done in  crbug.com/735289 , but users can still pop VK by clicking input. Lowering priority since  crbug.com/735289  will take care of most cases and reassigning.

sammiequon@ or yhanada@, is the goal to prevent the virtual keyboard from popping up on that PIN text entry? Can we just use inputmode="none" here? Is that what  crbug.com/815385  is for?

Just tried adding inputmode="none". VK still seems to trigger because the input type is "password" (works for without type="password"). Not sure if this is intentional...

shend@: Yes,  crbug.com/815385  looks the same issue.

Using inputmode="none" is simpler solution for preventing VK showing than doing asynchronous focusing, but it's internal clean-up rather than a bug.

Let's mark this bug as a duplicate of  issue 815385