Virtual keyboard API |
|||||||||||||
Issue descriptionIt would be helpful to have an explicit API for the virtual keyboard on touchscreen devices, particularly for showing/hiding the keyboard and querying its current state. Specific requirements are listed below. Partial solutions exist for most of these requirements, but they don't work consistently across platforms, and don't work for "floating" keyboards. Definitions: - VK: the virtual keyboard that appears on touchscreen devices for text input. - Visibility status: whether the VK is shown or hidden. - Bounding rect: the VK position and size in client coordinates. Core API Requirements: Users of the API must have the ability to: 1. Query the current VK visibility status and bounding rect. 2. Listen for events dispatched on changes to VK visibility status or bounding rect. 3. Programmatically change VK visibility status. Additional requirements: Users of the above API would typically want to disable default browser behavior related to the VK. In particular, they should have the ability to disable default behavior for: - changing VK visibility status, and - scrolling the cursor location into view when the VK appears. It must be possible to disable these behaviors individually. Event#preventDefault is not acceptable since this also prevents other unrelated behavior as side effects. Setting inputmode=none is a valid alternative, but this must be supported across all OS platforms and must not preclude use of the above API, particularly item #3.
,
Jun 27 2018
Assigning to shend@ since he already investigated this option.
,
Jun 27 2018
+bokan@ who wrote the VisualViewport API and +rbyers@, slightlyoff@, cwilso@ for web standards folks. Hi iroth@, I think there had been conversations about such an API in the past, but they never got too far. Since web standardization is a long process, I think it's important that other browser vendors have a similar need and that there are some people who are willing to champion the API. I'm not that familiar with web standardization, so passing on to folks who would know more :)
,
Jun 27 2018
,
Jun 28 2018
,
Jun 29 2018
Yeah, there's a ton of history here including a f2f discussion we had with all the other browser vendors around this (among other things) back in 2014: https://docs.google.com/document/d/1C6P3Mhza1jdMJyP9G6fr7n7zcXrCmwih1o2xohFVEhc/edit. The tl;dr is that most host OSes do not expose (and do not want to expose) this level of fine-grained control over the VK - IME is implemented as a higher-level abstraction and Microsoft and Apple in particular were opposed to trying to fake some lower level API in the browser even if it was somehow technically possible to do so. Maybe we should arrange a meeting between docs and web platform input folks to discuss the use cases further to see if we can come up with solutions which are implementable and standardizable?
,
Jul 5
,
Aug 22
iroth@ I'd like to prioritize this issue for our next quarter. Could you elaborate a little more on the list of use cases you have and the experience you want to provide on the web (not the APIs you think you might need). If you have a document that lists those that would be fabulous. I can also setup a meeting if you prefer to talk over GVC.
,
Sep 7
Hi Navid, we have a PRD from last year describing improvements we've made to Docs editors on touchscreen devices: go/docs-touch-input-prd (this link is Google internal). Happy to meet over GVC if you need more details. Thanks!
,
Oct 18
,
Nov 22
Issue 435871 has been merged into this issue.
,
Nov 27
hi paul, can you provide some inputs for prioritization on this?
,
Dec 7
,
Dec 7
This is in our 2019 planning for input-dev work. Although Since it needs quite a bit of discussions with other vendors as well it is not going to be ready in early 2019.
,
Dec 7
dvallet, gracec -- can you comment on whether Chrome OS should be considered as part of this discussion, or if we are diverged now?
,
Jan 1
I am not familiar enough with this landscape but if this work is going to improve how Docs works in ChromeOS tablets and VK, then this is important to us.
,
Jan 2
I think one of the driving use cases for this API would be improving VK experience on docs (on ChromeOS and other platforms). |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by kojii@chromium.org
, Jun 26 2018