It was 68.0.3440.25

Can't reproduce on Eve running 68.0.3440.25. Do you mind giving information about HW?

Can reproduce with login text field on scarlet.

When logged in, this works properly.

Hi Blake, would you mind taking a quick look at this one?

https://chromium-review.googlesource.com/920572
changed the behavior of the kv slightly.

I'm seeing the keyboard on startup move from states:
- initial
- load extension
- hidden

At this point, whenever OnTextInputStateChanged gets called, all the conditions are satisfied, and ShowKeyboardIfInTransientThreshold gets called.

Finally, the keyboard never actually gets shown because the last blur was unixepoc.

I'm having trouble understanding the original change and its motivation.

Thanks!

Zach or Omri, would you mind finding an owner? I have a proposed fix
https://chromium-review.googlesource.com/c/chromium/src/+/1107131
but would like to run this by someone who knows vk.

Hey, dtseng@!

What's happening with the keyboard transient blur threshold is that we separate text focus events into two groups: passive events (such as a web page immediately focusing a search text box when it loads) and active events (such as a user tapping on a text field to give it focus). The latter events should always cause the keyboard to come up and the former should only cause the keyboard to come up if the keyboard was already loaded recently. This is the transient blur threshold. The motivation for this is situations (such as the gaia login flow) where you type your username, press a button, and then a new page loads with the password field with focus. The user expects the keyboard to be loaded.

Based on the symptoms you described, it seems like the root cause here would be that your double-taps on the text fields are somehow getting incorrectly categorized as passive focus events. I assume these are being generated by the Touch Exploration Manager, but I'll dig into this to see if I can find more information about how these events are being routed and see if I can confirm my theory. 

Hi Blake, thanks for the insight!

How are passive focus events defined?

Accessibility sends an ipc to the target (hit tested) renderer to request focus programmatically. I'm unsure if this falls into the category of passive focus, but the code that does this programmatic setting lives in
content/r/accessibility/render_accessibility_impl.cc

Happy to take this offline in a chat if that could be easier. Thanks!

Friendly ping. Any updates?

Friendly ping again. Could I get some response to either any of the comments above or the potential change I sent? At least, I'd like to have a point of contact. Thanks.

Assigning to omrilio for further action.

Gentle ping -- Any updates? Is this still reproducible, or has it been resolved or become obsolete?

Still reproduces. I've gotten no responses on this bug for some time and zero interaction on a potential fix
https://chromium-review.googlesource.com/c/chromium/src/+/1107131

Please route to someone who can respond.

Assigning; hopefully to get on the radar. Thanks.

I'm following repro steps in comments #1 and #3, but can't repro on a Kevin with latest versions. 

Enable ChromeVox --> touch-explore to move focus to text field --> double-tap to activate focus on text field --> VirtualKeyboard always pops up. Same for log-in screen and after-log-in.

Thus closing this as "not reproducible".

If it's because I haven't fully understood the issue or missed some repro steps, please reopen and clarify. Thanks.

I can reproduce this 100% of the time:
- have ChromeVox enabled on login screen (in tablet mode); using a eve here.
- double tap on browse as guest
- double tap the address bar
- touch any vk key

result:
no VK spoken

Thanks a lot for the new repro steps. They really help. So the issue is "VK appears but no VK spoken feedback", rather than "can't open VK at all" as in the title? or both?

Anyway, I've managed to get "can't open VK" to repro, but only with the obsolete "old UI impl" of the VK, not the "new UI" that's being rolled out. Could you please confirm?

FYI. To force old/new UI, just disable/enable the "Material Design virtual keyboard" entry in chrome://flags, then chrome://restart for it to take effect.

No feedback is all I'm talking about. As for not opening, it's the same for a ChromeVox user (of which I am one) who cannot see the display. 

As FYI, I sent
https://chromium-review.googlesource.com/c/chromium/src/+/1107131

a while ago to address the issue but no one seems to own vk (or at least back a few months ago). The logic to show vk is really fragile (as you can see in the change above). Part of the problem is ChromeVox and other accessibility tools programmatically focus the text field, so that particular code path needs to be supported by vk to show itself.

After enabling the new md vk, it does seem things are better. I'm unsure all issues are ironed out since I've only given it a few minutes usage. I think this bug should continue until we are able to confirm. +dsexton@ for further testing (hoping you can help).

No worries, VK folks are following this now.

Glad to hear things seem better with the "new UI". Reassigning for further testing to confirm if the issue's been obsoleted by the "new UI" impl.

Any updates on QA testing with the new VK? Just wanna check if we can close this as "no longer reproducible". The new VK is already enabled by default.

Friendly ping!

As this doesn't repro on the "new UI" impl (mentioned in comment 17, somewhat confirmed in comment 19), and the "new UI" is now enabled by default, I'm closing this as "obsolete / not reproducible".

If there's still an issue, please file a new bug, instead of reopening this bug which was originally reported for the "old deprecated UI" impl. Thanks.