Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add integration with the Permissions API #70

Closed
reillyeon opened this issue Mar 20, 2019 · 3 comments · Fixed by #123
Closed

Add integration with the Permissions API #70

reillyeon opened this issue Mar 20, 2019 · 3 comments · Fixed by #123

Comments

@reillyeon
Copy link
Member

On #68 I commented that the new requestPermission() method should be defined in terms of the same permissions tokens as those used by the Generic Sensors family of specifications.

Alignment between these specifications will ease the transition for developers.

@rakuco
Copy link
Member

rakuco commented Oct 31, 2023

One of the comments in the thread mentions how this change wouldn't be noticeable to script, but it'd at least be visible to Permissions.query() and what it returns.

Another thing to consider when it comes to integration with the Permissions API is that it'd allow us to phrase the requestPermission() algorithms in terms of https://w3c.github.io/permissions/#requesting-more-permission, which is a good thing.

@rakuco
Copy link
Member

rakuco commented Nov 10, 2023

One of the comments in the thread mentions how this change wouldn't be noticeable to script, but it'd at least be visible to Permissions.query() and what it returns.

@reillyeon do you think this is a reasonable tradeoff? The proposal you linked to in the issue description makes sense and kind of matches the tokens we're considering using in the discussion in #64.

@reillyeon
Copy link
Member Author

I think given the symmetry with the Permissions Policy feature names exposing this detail to script that calls Permissions.query() is reasonable.

rakuco added a commit that referenced this issue Nov 14, 2023
…usage

This substantive and breaking change integrates the existing
requestPermission() calls with the Permissions API, so that we do not need
to essentially redefine the "request permission to use" algorithm here.

Additionally, calling requestPermission() is now a requirement, as
devicemotion, deviceorientation and deviceorientationabsolute events are
fired only when the permission state is "granted". This matches WebKit's
current behavior. Blink's plan is to follow suit in the near future.

The powerful feature names are identical to those proposed in #121:
"accelerometer", "gyroscope", and "magnetometer", which match the low-level
sensors that provide the data in the events fired by this specification.
These names also match those in the Accelerometer, Gyroscope and
Magnetometer specifications, which allows developers who want to transition
between these APIs to avoid having to request access to different powerful
feature names with the same goal.

Also similarly to #121, the idea is to:
- Require "accelerometer" and "gyroscope" for the devicemotion event.
- Require "accelerometer" and "gyroscope" to provide relative
  orientation data for the deviceorientation event, and additionally
  "magnetometer" to fall back to absolute orientation data.
- Requires "accelerometer", "gyroscope", and "magnetometer" for the
  deviceorientationabsolute event.

DeviceOrientationEvent.requestPermission() now takes an optional `absolute`
argument (defaulting to false) to specify whether it will also request the
"magnetometer" permission.

IMPORTANT: As far as I can see, the WebKit implementation does not integrate
with the Permissions API. It therefore does not use the powerful feature
names described above, nor does support the new `absolute` argument or the
requesting of different permissions depending on whether developers want to
access to absolute orientation data.

Fixes #70.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants