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 On Wednesday, June 17, 2026 at 6:11:13 AM UTC-7 Mike Taylor wrote: > 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" ^__^). > On 6/17/26 7:15 a.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESensor%3EDeviceOrientation%22> > > *Web Feature ID* > device-orientation-events > <https://webstatus.dev/features/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 <http:///features#tags:device%20orientation>, device > motion <http:///features#tags:device%20motion>, permissions > <http:///features#tags: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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 > <https://chromestatus.com>. > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3281ee.341e3fe1.243138.0a95.GAE%40google.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3281ee.341e3fe1.243138.0a95.GAE%40google.com?utm_medium=email&utm_source=footer> > . > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4eeb8233-4cb3-4cda-8cbb-ca882a163f19n%40chromium.org.
