Similar (possibly the same) issue with new tab.  When you open new tab page, focus goes to the omnibox but VK doesn't come up.

At least previously, not showing when a new tab is created was WAI. Lots of pages auto-focus textboxes (eg. old Settings), but we don't want to cover half the screen with a vkey whenever that happens. With the NTP, we wanted to give users the chance to look at the suggested pages, tap voice input, etc.

For signing into a Google account, that seems like we should keep the vkey active. They might need to focus the password field in response to a user event.

I definitely get not wanting to trigger VK on ANY focused text box. There are a few cases though where we probably DO want to. The omnibox right after opening a new tab seems like a pretty likely case.

Right now it just feels really clumsy.

Agreed. I think I misremembered what  Issue 368267  was about -- we wanted to hide the vkey when switching between two tabs that both have focus, but creating a new tab should be a special case.

I agree with both. There are some cases which we should fix.
Example - on start screen when signing up to a new user, I find it weird that after entering my email address, VK goes away when the password field appears.
This can probably be generalized to a form flow of inputs.

We may be able to change the sign-in page code to trigger the VK explicitly for fixing the sign-in case.
For new tab case, I'm not sure that hiding quick accesses by the VK is good.
If we can have generalized criteria of which cases we should keep the VK as Omri said, it would be great.

I actually am starting to think that the problem is very specific to Google login. We are doing something weird there.
As any other website I could find that uses the approach of switching pages for logging in works for me.

See attached video of an example site tinkercad.com 

Deleted: May 10 2017 11-57 PM.webm 2.5 MB

	May 10 2017 11-57 PM.webm 2.5 MB View Download

We wait hiding keyboard if an input element is re-focused in 100ms after an element is unfocused. 
I think in login case transition is taking more than 100ms.

I will check what exactly happens in login screen case.

oka@, re comment #9, it looks like in the login case it never gains focus back. I'd assume that if focus comes back it should just re-open the virtual kebyoard. No?

Just reproduced in MTV-QD5 on buddy and sumo
In any build of Chrome OS 56, VK appears automatically for password input element for any website, like gmail.com or tinkercad.com

But it never appears automatically on the same device after upgrading to v59, was there any change to especially change it, or it's a regression bug?

Friendly ping - have customers following up about this issue and it hasn't been revisited for a while. Looks like there was an intentional change around this in 
https://bugs.chromium.org/p/chromium/issues/detail?id=642513 (internal only)?

blakeo@ could you take a look?

From reading through this bug and the linked bug, it seems as though the real fix here might be to undo https://codereview.chromium.org/2699533009 and apply the app-specific fix to pin-pad as suggested in https://bugs.chromium.org/p/chromium/issues/detail?id=642513#c44

I prototyped an alternate fix that seems to work. If the keyboard is dismissed and then re-invoked within 2 seconds then it gets considered as a "transient dismissal of focus", and regardless of the source of the re-focus, the keyboard should be re-invoked. If the keyboard hasn't been shown in a while, then it falls back to oka@'s original logic where asynchronous focus invocations will not show the keyboard. 

For reference, the gmail password field takes 1.5 seconds to gain focus from the time that you push "next" from the username field, although if there's network latency involved, 2 seconds may need to be increased. 

https://bugs.chromium.org/p/chromium/issues/detail?id=397988 is a different symptom of the same issue

any updates?

Ping, any update?

Issue 801864 has been merged into this issue.

The "transient blur" heuristic has been implemented for a while and is relatively stable so I'm going to close this as Fixed.