Add permission request API #68
Merged
+268
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is based on the Notification API's requestPermission(). |
|
I landed initial support in WebKit via https://bugs.webkit.org/show_bug.cgi?id=195329 although it is still disabled by default given there was no spec PR yet. |
|
W3C has recorded a license commitment for this contribution, so I'm clearing the IPR check. |
|
Marked as non substantive for IPR from ash-nazg. [Meant to reflect commitment-received, but tooling doesn't yet show that option.] |
domenic
reviewed
Mar 13, 2019
cdumez
force-pushed
the
requestPermission_api
branch
3 times, most recently
from
7326206 to
e8765ac
Compare
|
I moved the user gesture check a bit later to allow websites to detect if they already have permission without a user gesture, as proposed in #57 (comment). |
reillyeon
reviewed
Mar 14, 2019
kenchris
reviewed
Mar 15, 2019
Add requestPermission() static operation to both DeviceOrientationEvent and DeviceMotionEvent so that JavaScript can request permission to use the API so that user agents may ask the user before sharing the device orientation & motion with the page. Fixes: w3c#57
cdumez
force-pushed
the
requestPermission_api
branch
from
e8765ac to
deeac36
Compare
|
All - please submit your remaining review comments by EOB next Monday 18 March. |
|
Hearing no further concerns I will merge this PR now. Thank you @cdumez for the PR and reviewers for your insightful comments. |
|
(For completeness, submitted a separate PR #69 for a typo fix.) |
|
Thanks for your work on this @cdumez. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1536382 to track this for Firefox. |
|
For future reference, we're tracking this in https://bugs.chromium.org/p/chromium/issues/detail?id=947112 for Chromium. |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Apr 18, 2019
…ion}Event STILL WIP, BLOCKED ON https://crbug.com/952824 Implement w3c/deviceorientation#68, which has added a static requestPermission() method to both DeviceOrientationEvent as well as DeviceMotionEvent. Scripts wishing to listen to these events (as well as deviceorientationabsolute) must first request permission from users by calling those methods; until then, any event listeners are registered but never triggered. Permission granted via requestPermission() is checked for after other existing checks (if the requires feature policy checks fail, for example, we still do not register the event handler at all). Implementing this requires changing how sensors permissions work in the browser: so far, users could choose between always allowing and always blocking sensor access. It is now possible to choose "Ask" as an option, in which case a modal prompt asks the user for access (dismissing the prompt or choosing "Block" both mean "Block" to the new web API). In any case, we keep "Allow" as the default option for backwards compatibility. Specifically: * In the desktop UI, it is possible to choose between "Allow", "Ask" and "Block" for sensors in chrome://settings/content/siteDetails and between "Allow" and "Ask" in chrome://settings/content/sensors. * On Android, it is currrently not possible to have per-site sensor settings; on the global site settings, we now have a tri-state choice between "Allow", "Ask" and "Block". Bug: 947112 Change-Id: I0e34b48fd21d56d6ac35ad55f69f992065a4bc62
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jun 19, 2019
…ion}Event Implement w3c/deviceorientation#68, which has added a static requestPermission() method to both DeviceOrientationEvent as well as DeviceMotionEvent. Permission granted via requestPermission() is checked for after other existing checks (if the requires feature policy checks fail, for example, we still do not register the event handler at all). The spec is somewhat vague in how permission handling should be implemented. For Chromium, we have settled on the following behavior: * If sensor access is set to "Allow", event listeners can be registered at any time, and calling requestPermission() returns a promise that resolves to "granted". * If sensor access is set to "Block", event listeners will only receive a single null event, and calling requestPermission() returns a promise that resolves to "blocked". * If sensor access is set to "Ask", event listeners will only receive a single null event until requestPermission() is called and access is granted (i.e. the user explicitly clicked "Allow" in the permission bubble, any other behavior including dismissing the bubble results in denial). If requestPermission() is NOT called through a user gesture, it will return a promise that rejecs with a NotAllowedError DOMException. If access is granted, requestPermission() returns a promise that resolves to "granted"; if access is denied, requestPermission() returns a promise that resolves to "blocked". Bug: 947112 Change-Id: Ibb6ad43b78ca54189cf8f7ef802a4f812c5030df
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jun 20, 2019
…ion}Event Implement w3c/deviceorientation#68, which has added a static requestPermission() method to both DeviceOrientationEvent as well as DeviceMotionEvent. Permission granted via requestPermission() is checked for after other existing checks (if the requires feature policy checks fail, for example, we still do not register the event handler at all). The spec is somewhat vague in how permission handling should be implemented. For Chromium, we have settled on the following behavior: * If sensor access is set to "Allow", event listeners can be registered at any time, and calling requestPermission() returns a promise that resolves to "granted". * If sensor access is set to "Block", event listeners will only receive a single null event, and calling requestPermission() returns a promise that resolves to "blocked". * If sensor access is set to "Ask", event listeners will only receive a single null event until requestPermission() is called and access is granted (i.e. the user explicitly clicked "Allow" in the permission bubble, any other behavior including dismissing the bubble results in denial). If requestPermission() is NOT called through a user gesture, it will return a promise that rejecs with a NotAllowedError DOMException. If access is granted, requestPermission() returns a promise that resolves to "granted"; if access is denied, requestPermission() returns a promise that resolves to "blocked". Bug: 947112 Change-Id: Ibb6ad43b78ca54189cf8f7ef802a4f812c5030df
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add requestPermission() static operation to both DeviceOrientationEvent and DeviceMotionEvent
so that JavaScript can request permission to use the API so that user agents may ask the user
before sharing the device orientation & motion with the page.
Fixes: #57
Preview | Diff