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

> 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.

I don't think malicious case is interesting because it can only affect the website itself. A more common scenario is the lack of knowledge / testing that results in a website being non-functional on iOS devices. Given the number of websites that lock themselves to only support Chrome in wild, I don't think we want to take that kind of risk.

> 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.

I don't think permission makes much sense for this feature since it has such small end-user impact when it works, and the end user are unlikely to fully understand the implication of the issue otherwise.


-- 
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-606926951