Re: [w3c/editing] inputPanelPolicy as a way to control software keyboard (#225)

That is a good point. I think we somehow missed to address this part in the explainer, but we did discuss about it when we were reviewing this API with our OS team. 
The user may not want some sites to have the ability to show or dismiss their VK.  These sites may be malicious and attempt to DOS the user by denying them access to their VK.  Alternatively, the site may simply be poorly implemented and the user would prefer to lock the site into auto behavior rather than have their VK be mismanaged.
To prevent DOS attacks and combat poor experiences created by authors that improperly use the APIs, a site must receive [permission ](https://www.w3.org/TR/permissions/#enumdef-permissionname) to explicitly control the VK using the show and hide APIs.  Additionally, using the value manual for the virtualKeyboardPolicy is equivalent to auto unless the site has received permission to control the VK.  The rationale is that manual effectively disables automatic management of the VK, and if the site hasn’t received permission to explicitly control it then the keyboard may become inaccessible to the user.
The proposed [permission name](https://www.w3.org/TR/permissions/#enumdef-permissionname) is “virtualkeyboard”.
Permission should be requested when the show or hide methods are called, or when an editable element with a virtualkeyboardpolicy of manual is focused or tapped.

Additionally, calls to show or hide the keyboard should only be honored (or lead to a permission prompt) when they are received from a realm with an active document which has received some user interaction.
Thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/225#issuecomment-606900722