Update VirtualKeyboard API User Activation Requirements

[neeraj-kumar-at-google]

Author: nekumar@google.com

TL;DR

The VirtualKeyboard API's show() method requires sticky user activation, which is lost during same-origin navigations, preventing programmatic virtual keyboard display after redirects (e.g., for form fields). This document examines solutions: persisting sticky activation on the same origin (simple, but security concerns), persisting transient activation (conservative, complex), making it a permission (user control, friction), or removing restrictions (flexible, high abuse risk). The most promising options are same-domain sticky activation or a permission-based approach. The author is open to other suggestions from the experts in this group.

Update VirtualKeyboard API User Activation Requirements

Background

The current VirtualKeyboard API's show() method requires sticky user activation to be called (User Activation). This means a user must have interacted with the page at least once. While this prevents potential abuse, it introduces friction in scenarios involving same-origin navigations. For example, if a user action on www.example.com redirects them to a form on www.example.com/form, the sticky activation state is lost during the navigation. This prevents developers from programmatically showing the virtual keyboard (VirtualKeyboard.show()) when the new page loads, even if the intent is to focus a form field and improve user experience.

Considerations

The core issue is that sticky user activation does not persist across page navigations, even within the same origin (User Activation). When a user is navigated from one path to another (e.g., /index to /form), the new page loads in a state without user activation. This design choice, while sound for general security, limits the ability to create seamless experiences where a virtual keyboard is expected to appear upon arrival at a specific page section, such as an input field in a form. Developers cannot reliably call navigator.virtualKeyboard.show() on page load after a same-origin redirect, as the required sticky activation is absent.

Potential Solutions

Here are a few potential solutions to address this limitation:

a. Make Sticky Activation Persist on the Same Origin

• Description: Allow the sticky user activation state to persist across navigations, as long as the navigation is within the same origin (domain and subdomain) (User Activation).
• Pros:
  • Directly solves the problem for same-origin redirects.
  • Relatively simple to understand and implement.
  • Maintains the user-has-interacted-at-least-once principle within the origin.
• Cons:
  • Potentially broadens the scope of sticky activation, which might have unintended security implications if not carefully (e.g., a single interaction on any page of a domain grants activation to all pages).
  • The duration of this persisted activation would need careful definition.

b. Persist Transient Activation Across Same-Origin Pages & Allow show()

• Description: Keep sticky activation page-specific. However, allow transient user activation (User Activation) to persist across same-origin navigations for a very short duration. Additionally, modify the VirtualKeyboard.show() requirement from sticky to transient activation.
• Pros:
  • More conservative than persisting sticky activation, as transient activation is time-bound.
  • Still enables the desired UX for immediate post-redirect keyboard display.
• Cons:
  • Adds complexity by introducing cross-page transient activation.
  • Defining the expiration and consumption rules for cross-page transient activation could be challenging.
  • Shifting show() to require transient activation might break existing use cases expecting sticky activation's persistence within a single page.

c. Make VirtualKeyboard API a Permission

• Description: Treat programmatic control over the virtual keyboard (especially show()) as a permission that the user can grant to a website, similar to how microphone or location access is handled.
• Pros:
  • Gives users explicit control over which sites can manipulate the keyboard.
  • Aligns with the trend of making powerful web features permission-based.
  • Once granted, the site could potentially show the keyboard even without recent interaction, including after redirects.
• Cons:
  • Adds user friction through permission prompts.
  • Users might not understand the implications of the permission.
  • Overhead for both browsers to implement and developers to handle permission states.

d. Remove User Activation Restrictions for show()

• Description: Allow navigator.virtualKeyboard.show() (VirtualKeyboard.show()) to be called without any user activation requirement.
• Pros:
  • Maximum flexibility for developers.
  • Trivially solves the redirect problem.
• Cons:
  • High potential for abuse: sites could programmatically show the keyboard atany time, leading to a poor user experience (e.g., keyboard popping up unexpectedly).
  • Goes against the general trend of restricting potentially disruptive APIs.

Conclusion

The current sticky activation requirement for VirtualKeyboard.show() limits valid use cases involving same-origin navigations. Solutions like persisting sticky activation within the same domain (a) or using a permission-based approach (c) seem to offer the most promising balance between developer needs and user protection. Further discussion and security review are needed to determine the best path forward. The author of this request is also open to alternatives that are not discussed above but may be better overall.

Pros and Cons Summary

Solution	Pros	Cons
a. Persist Sticky Activation on Same Domain	- Solves same-origin redirects. - Simple concept. - Maintains interaction principle within domain.	- Broader scope, potential security risks. - Duration needs definition.
b. Persist Transient Activation & Require for show()	- More conservative, time-bound. - Enables post-redirect UX.	- Complex cross-page transient activation rules. - Potential to break existing `show()` use cases.
c. Make VirtualKeyboard API a Permission	- User control. - Aligns with permission trends. - Persistent ability once granted.	- User friction (prompts). - User understanding of permission. - Implementation overhead.
d. Remove User Activation Restrictions	- Maximum developer flexibility. - Trivially solves the redirect issue.	- High abuse potential. - Poor user experience risk. - Against the trend of restricting disruptive APIs.