I think this is actually the intended behaviour by the docs team. iroth@ could you help verify?

Yes, this is the intended behavior.

Docs is not contenteditable. It's used not only for editing but also for reading, and many editing workflows do not involve the keyboard. In these cases the virtual keyboard should remain hidden. Single tap tends to show it accidentally and this quickly becomes frustrating and annoying.

There are a couple supported ways to bring up the virtual keyboard:
1. double tap anywhere on the document canvas
2. single tap directly on the blinking cursor

Thanks iroth@! This is actually quite a common "bug" that we receive on the VK side; are there any plans to make this more discoverable? I didn't know about the double tap until I read the bug about double tap being broken on Chrome.

Filed b/122855722 to track this from the Docs side.

Fantastic, thank you! I'll close this bug then to take it off the VK queue.

I just want to provide a bit more details from a related bug.

Needing to double-tap in the doc body in order to activate VK while you only need to 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.

Instead of trying to educate user on an one-off/exception gesture, I recommend looking into physical keyboard detection and smartly display Docs in the applicable mode. If a physical keyboard is connected, use the web app paradigm. If no physical keyboard is connected (i.e. need to use virtual keyboard), adopt the Android app paradigm with an explicit option for edit mode.

The Docs Android paradigm of showing a separate button to activate the virtual keyboard was something we considered and tested, but we didn't get a clear signal. I think this is an acceptable alternative though. This could exist simultaneously with double-tap and tap-on-cursor as an additional entry point to touchscreen typing.

However we do want to avoid having separate "modes" in the web editor. The button would simply show the virtual keyboard. Also I don't think it's possible to reliably detect hardware keyboard in a web app. But we can detect whether the device has a touchscreen and only show the button in this case.