Closed anssiko closed 4 years ago
Generic navigator.permissions.request()
- Spec: WICG spec spun off from Permissions API that defines navigator.permissions.query()
- Implementations: none
FWIW, on the Chrome side, Implement Permissions.request()
and Permissions.revoke()
has been started, which is still blocked on Implement navigator.permissions.requestAll()
, but I can't find requestAll
in the spec (it seems @mounirlamouri can say more about that).
I am in favor to try to push the generic approach, especially because I do find it worthwhile to explore the "multiple permissions at once" case given general permission fatigue.
Related: Permissions API issue https://github.com/w3c/permissions/issues/191 discusses bundling of permissions as a generic mechanism.
Since this discussion rightly is split across multiple repos, a clarification:
This issue https://github.com/w3c/sensors/issues/388 is to explore what is the preferred mechanism (if any) to programmatically request permission for concrete sensors that subclass Sensor
. That mechanism might be an affordance specified in a future version of the Permissions API spec, its extension spec, or elsewhere.
@anssiko it might help if we compose a list of sensors that may need/want a permission API?
@rwaldron, the list of sensors some implementers may want to gate behind a permission is basically all the concrete sensors that subclass Sensor
: https://www.w3.org/das/roadmap
Currently "legacy" DeviceOrientationEvent
and DeviceMotionEvent
are behind a permission gate on iOS and Chrome is WIP, while the corresponding modern APIs are not.
@rakuco @reillyeon can probably comment on Chrome's permission-related plans for the APIs that subclass Sensor
.
My proposal is to remove the permissions-related side effects from Sensor.start()
and add an explicit Sensor.requestPermission()
method. The reason to separate these is to avoid needing to start a sensor in the main frame just so that the page can request permission to use that sensor from a worker. In terms of avoiding permission prompts that come out-of-context (which was the argument on the Payment Request API) there isn't a meaningful difference between having two methods rather than one.
To @rwaldron's question, all sensor types will have a requestPermission()
API. It is up to implementations how to manage permissions internally. Chrome currently tracks a single "sensor" permission type. The design of the API should, for example, allow an implementation to require permission for some sensors and not others, or to require permission for some polling frequencies and not others.
@reillyeon wrote:
My proposal is to remove the permissions-related side effects from Sensor.start() and add an explicit Sensor.requestPermission() method.
All - please let us know if you have any concerns with this proposal.
Hearing none, I'd like us to start baking a PR to specify this in detail.
Discussed at TPAC 2019 F2F. Closing this issue without adding a static requestPermission()
API. Relying on the existing side-effects in Sensor.start()
and the Permissions API for more advanced use cases such as permissions bundling.
Generic Sensor API was defined with an expectation the generic
navigator.permissions.request()
would materialize at some point, but sincerequest()
seem not be gaining support among implementers we should look at other options. Currently, two approaches to programmatically request permission have been coined and one of them tried on the web platform:navigator.permissions.request()
navigator.permissions.query()
Foobar.requestPermission()
Opened this issue to gauge interest to revisit concrete
requestPermission()
again given it has been getting some traction recently (see Device Orientation). If there's support for this idea, we could add informative guidance to Extensibility for concrete spec authors that subclassSensor
to utilize.