Intent to Ship: DeviceOrientation Events permission request API

[Chromestatus]

Contact emails

t...@google.com

Explainer

https://www.w3.org/TR/orientation-event/#dom-deviceorientationevent-requestpermission

Specification

https://w3c.github.io/deviceorientation/

Design docs

https://docs.google.com/document/d/1zrhTooMd0Pqee8R0dJggDUeAgvt_3na_MaVefPpLG7o/edit?tab=t.0

Summary

Allows web developers to call Device{Motion,Orientation}Event.requestPermission() to ask the user agent for device orientation and motion data to be shared with the page. Those two static methods return a promise that resolves to either "granted" or "denied" based on whether the user has allowed the user agent to share sensor data with pages.

Blink component

Blink>Sensor>DeviceOrientation

Web Feature ID

device-orientation-events

Motivation

The new API was added to the Device Orientation spec in https://github.com/w3c/deviceorientation/pull/68 following security concerns raised in https://github.com/w3c/deviceorientation/issues/57.

Initial public proposal

https://github.com/w3c/deviceorientation/issues/57

Search tags

device orientation, device motion, permissions

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

The Chromium behavior is heavily tied to the permissions for the Sensors setting, which is being changed from Allow/Block to Allow/Ask/Block. This transition will be in two phases, where we first introduce the tri-state, but still default to Allow. Eventually will intend to move to an Ask-by-default state. In this latest stage, websites that register event listeners will not receive motion or orientation events until they call requestPermission(). This is the behavior as defined in the specification, and as is currently shipping in WebKit on iOS.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1536382)

WebKit: Shipped/Shipping (https://github.com/w3c/deviceorientation/issues/57#issuecomment-498417027) Shipping on iOS.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

On WebView the sensor permission is granted by default, so adding the 2 APIs will have no effect on applications, as `requestPermission()` will always return "granted".

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes
On the Android WebView, sensor access is always allowed, so this API will always return a promise that returns "granted".

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/orientation-event/motion/requestPermission.https.window.html https://wpt.fyi/results/orientation-event/orientation/requestPermission.https.window.html?label=experimental&label=master&aligned

Flag name on about://flags

No information provided

Finch feature name

DeviceOrientationRequestPermission

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=947112

Adoption expectation

Websites that have a valid reason for accessing sensor data (e.g. mobile games) will call the API to access the detailed sensor data.

Adoption plan

Initially the feature will have no effect as long as the default permission is ALLOW. We plan on eventually moving this to ASK by default, requiring a call to requestPermission().

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	151
DevTrial on desktop	150
Shipping on Android	151
DevTrial on Android	150

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5915984063889408?gate=6183183769403392

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM1 % filing a Mozilla standards position, mostly as an FYI that we're shipping this (I don't think a 7 year old bug w/ no activity counts as "in development" ^__^).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3281ee.341e3fe1.243138.0a95.GAE%40google.com.

[Alex Russell]

The naming doesn't seem to be aligned with other device APIs; e.g. Web HID and WebUSB have `requestDevice()` methods that return the capability:

  https://developer.mozilla.org/en-US/docs/Web/API/WebHID_API

Web Serial does something similar from `navigator`:

  https://developer.mozilla.org/en-US/docs/Web/API/Navigator/serial

and Web MIDI has an explicitly named method and options that align with the Permissions API:

  https://developer.mozilla.org/en-US/docs/Web/API/Navigator/requestMIDIAccess

It's also weird to have this method return the permission state, rather than a capability.

Have you consulted with the TAG on consistency for naming and API shape here? Should we be proposing a more sympatico version?

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.