DRAFT Objectives Define an API to allow web applications access to keys normally reserved for browser or platform shortcuts. Goals for the API are:
Background See Chromium issue 84332. Issues 71476, 84288 and 32787 provide additional background. Approaches Approaches to defining an API can generally be characterized on four properties:
Some potential approaches are outlined below. Enable/Disable All-But-One Reserved Keys The simplest API for applications to make use of is one which completely disables browser accelerated reserved keys, leaving them available for the application to use. However, we’ll generally need to retain one hot-key to re-enable them, as an escape hatch back to normal behaviour. Escape via Hot-key Specifying a fixed hot-key presents similar issues to reserved keys in general, in that the combination may be one the web app wanted to use, so it makes more sense for the application to specify the hot-key combination it wants the user to use to restore accelerators, and for the browser to arrange to display that. The browser would also need to verify that the selected combination was actually possible for the user to press. For consistency across applications, it may be better to let applications specify a list of suitable combinations, and let the user choose which to use, across all installed applications. Associate with Full-screen Alternatively, if we assume that most apps requiring access to reserved keys will typically run full-screen, access to reserved keys might be dependent upon the full-screen state of the application, relying on the full-screen escape key to provide a way out. This is a problem for applications which need to use the Escape key, so would only really work in conjunction with an application-chosen escape-fullscreen hotkey. More fundamentally, many if not most games will require access to reserved keys, but are not designed to be run full-screen. Enable/Disable Individual Reserved Keys The API could allow applications to enumerate the reserved keys and to choose to disable those which it requires access to itself. This is complex for the application, and may lead too counter-intuitive behaviour for the user, since some browser accelerators then work while others don’t. Reconfigure Individual Reserved Keys A variant on enabling/disabling individual reserved keys is to allow applications to reconfigure them, to move them off combinations that the application itself wants to use. This maintains hot-keys for all actions, but even if the user is made aware of such changes, the level of user confusion is likely to be significant. This might be considered as an auxiliary API, used by applications which have disabled all accelerators, to voluntarily make specific ones (e.g. close Tab) available via a different key combination. Enable/Disable Most Reserved Keys Rather than enabling/disabling all reserved keys, a limited set of hot keys could be retained, such as Close Tab, providing a straightforward escape for the user. The main problem with this is that the Close Tab hot-key, for example, is one of the ones most commonly requested to be disabled by web applications, so this might work well for many applications, but not for all. Applications will also suffer from ambiguity as to what “most” means across different browsers. Enable/Disable Reserved Key Sets A variation on disabling all or most reserved key accelerators is to bundle them into sets of related reserved keys which applications may choose to disable, thereby providing a balance between fine-grained controls and blanket enable/disable. Again, the ambiguity as to which reserved keys appear in which sets poses a problem. Related Issues:
|
|
For Developers > Design Documents >
Reserved Keys API |