Thanks for the report. What web page were you testing this on? Is it just the new tab page?

It's not always predictable. But sign-in page is another example.

1. On a new tab page, tap on user account avatar and select Add account
2. Sign in page is displayed with edit cursor blinking in the Email or phone filed but keyboard is not up

1. Go to yahoo.com
2. Keyboard this time actually is automatically up while cursor is blinking in search field
3. Close the keyboard
4. Tap Sign in in upper right corner of page
5. Sign in page is displayed with cursor blinking in email field but keyboard is not up in this case either

Thanks for the repro instructions. I believe in these two particular cases, it's WAI.

To prevent websites from abusing the VK, we've historically had a rule that only a user gesture can activate the VK. Sometimes, websites can focus arbitrary on a text field, and we would not show the VK. So a blinking cursor does not imply that the VK should show.

There are some weird exception cases where we do automatically show the VK upon focus, which can lead to unexpected inconsistencies.

I'm definitely open to making the VK show/hide experience a lot more consistent and predictable (with safeguards against abuse), but for now I believe this is not a bug.

+pcovell@, do you know if we have a tracking bug for a more consistent VK show/hide criteria? Otherwise, we can just make this a feature request or something.

Having some consistency and predictability would be great. What I worry most are two things.

(1) It is an adopted UI paradigm that when a blinking cursor is in a field, it's editable/type-able immediately. It's a cue that users are used to on desktop or otherwise with a physical keyboard. Deviating from that is confusing.

I may not understand the details behind the potential abuses. But if we want user to tap or gesture in order to activate the VK, I strongly recommend enforcing apps/sites not to focus on a field when it is opened/loaded (or we revert their event request somehow). My general experience on my Pixel phone and iPhone seem to follow this "rule."

(2) It's not consistent among our own Google apps. I logged a related issue regarding editing in a Google doc (https://bugs.chromium.org/p/chromium/issues/detail?id=921409). Needing to double-tap in the doc body in order to activate VK while you only need a single-tap everywhere else is very confusing (and seem broken).

The Android Google Docs app either brings you into editing mode immediately with the keyboard up, or it opens a doc in a non-edit mode without keyboard (you have to tap an option to put the doc in edit mode). This is an interaction behavior that is common and understood, even though it requires an extra click/tap.


Hope this helps clarify. Just wanted to elaborate with more details.

(1) Yeah I agree it's more intuitive to have cursor and VK 'in sync'. There was a whole thread about it in 642513. Basically, it's a tricky balancing act between showing the VK too much vs showing too little. I think we are currently leaning on the more conservative side, main reason probably being: it's more annoying for users if VK pops up when it shouldn't versus not popping up when it should.

(2) Yeah docs is a special case. I'm not exactly sure about the details. I have a feeling that it might be an experiment, because on other platforms/browsers, tapping the body just brings up the VK.

I agree this is something we should rethink.