Bug 19771 - Need way to determine what keys are supported on device.
Summary: Need way to determine what keys are supported on device.
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: UI Events (show other bugs)
Version: unspecified
Hardware: PC All
: P2 enhancement
Target Milestone: ---
Assignee: Gary Kacmarcik
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-30 06:43 UTC by Glenn Adams
Modified: 2013-05-17 16:42 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Adams 2012-10-30 06:43:02 UTC
On devices that use RCs (remote controls), it is often the case that the set of supported keys vary. For example, one RC might have red, green, blue buttons, while another might have red, green, blue, yellow. There is also much variation in supported keys for media related functions and other device specific extensions.

At present DOM-3 Events does not specify that any particular physical key must be supported on a device. But rather, simply defines which key values are to be used when a key is present. [Though even this is ambiguous since if some physical key is present, there is nothing in DOM-3 Events which mandates a specific key (string) value be used.]

In order to address this, I suggest defining an appropriate API in DOM-3 Events, e.g.,

partial interface Navigator {
  DOMString? getKeyLabel(DOMString keyString, optional DOMString locale);
}

The method getKeyLabel() returns a non-empty string that denotes a device dependent label for a key that generates keyString, or, if no key generates keyString, then returns null. If locale is specified and non-empty, and if a locale specific label is available, then it should be returned instead of a default label.

The returned label should be suitable for presentation to the end-user in a user interface in order to indicate to the user the label of the key found on the (physical or virtual) key.

In all cases, either a non-empty string or null shall be returned.

It might also be desirable to provide an additional method, such as:

partial interface Navigator {
  DOMString[] getKeyStrings();
}

which returns all key strings supported by the device [that could be used as an argument when calling getKeyLabel()].

This latter would be useful for making effective use of keys for which no standard key string has yet been published.
Comment 1 Hallvord R. M. Steen 2012-11-02 08:28:57 UTC
The implementation should have some protection against fingerprinting, for privacy reasons.
Comment 2 Gary Kacmarcik 2013-05-17 16:42:19 UTC
We're trying to do something similar with queryKeyCaps in UI Events.

Since this certainly won't be part of D3E at this point, I'm changing the component to "UI Events" so we can consider it for that spec.