Confirmed users
657
edits
WebAPI/Navigator.hasFeature: Difference between revisions
no edit summary
(→"api" namespace: See https://bugzilla.mozilla.org/show_bug.cgi?id=1009645#c49) |
No edit summary |
||
| Line 1: | Line 1: | ||
= Navigator. | = Navigator.hasFeature API = | ||
== Use Cases == | == Use Cases == | ||
| Line 12: | Line 12: | ||
[NoInterfaceObject] | [NoInterfaceObject] | ||
interface NavigatorFeatures { | interface NavigatorFeatures { | ||
Promise hasFeature(DOMString name); | |||
Promise getFeature(DOMString name); | Promise getFeature(DOMString name); | ||
}; | }; | ||
| Line 18: | Line 19: | ||
== Semantics == | == Semantics == | ||
getFeature | Both hasFeature and getFeature accept string arguments to denote the feature names. getFeature resolves the promise with an undefined value if the feature name passed to them is unknown. For the "api" and "manifest" namespaces as described below, hasFeature will fullfill the promise with a true value if the feature exists on the "platform" (which means the current state and version of the hardware and the UA software) albeit hidden behind some runtime permissions, and it will fulfill the promise with a false value if the feature doesn't exist on the "platform". The type of that value depends on the feature being queried. The idea is that hasFeature should be used for mere existence tests, and getFeature should be used for queries involving asking more information about a feature, such as the size of something. | ||
The feature name specifies a namespaced value in the following form: | The feature name specifies a namespaced value in the following form: | ||
| Line 32: | Line 33: | ||
=== "api" namespace === | === "api" namespace === | ||
Names under this namespace have this general form: "api.window/worker.InterfaceName.propertyName" | Names under this namespace have this general form: "api.window/worker.InterfaceName.propertyName". These names can be used with hasFeature. | ||
We currently do not support any feature names for the worker context. The following are the names that we support: | We currently do not support any feature names for the worker context. The following are the names that we support: | ||
| Line 54: | Line 55: | ||
=== "manifest" namespace === | === "manifest" namespace === | ||
Names under this namespace have this general form: "manifest.name" or "manifest.name.value" | Names under this namespace have this general form: "manifest.name" or "manifest.name.value". These names can be used with hasFeature. | ||
They are needed to detect whether specifying a field named "name" in the webapp manifest (optionally with a value of "value") will have any effect on the platform. The following names are currently recognized: | They are needed to detect whether specifying a field named "name" in the webapp manifest (optionally with a value of "value") will have any effect on the platform. The following names are currently recognized: | ||