I've filed a Mozilla standards position: https://github.com/mozilla/standards-positions/issues/1428
> Can th is doc be made public? That one discusses restricted bugs, so I can't make it public. I've instead created a brief design doc, which I've shared with blink-dev: https://docs.google.com/document/d/1HUT3myrlp5YsnzWUTZz7ETA5ZaJFM1fQtdFj_SyPHjQ/edit We can indeed explore an alternative design in parallel. If this isn't a blocker, I'd like to request other LGTMs as well: https://chromestatus.com/feature/5915984063889408?gate=6183183769403392 On Wednesday, June 24, 2026 at 5:21:52 PM UTC+2 [email protected] wrote: > I agree we should ship to match WebKit here. But also +1 to the question > of whether Mozilla has an opinion on the API shape and have any interest in > going beyond what WebKit has already done, such as in the direction Alex > suggests. > > Rick > > On Wed, Jun 24, 2026 at 11:16 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> On Wednesday, June 17, 2026 at 2:16:09 PM UTC+3 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 >> >> >> Can this doc be made public? >> >> >> >> >> *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 desktop151 DevTrial on desktop150 Shipping on Android151 >> DevTrial >> on Android150 >> >> *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/97b17ff4-35ab-4eee-9d70-70ba6feb278dn%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/97b17ff4-35ab-4eee-9d70-70ba6feb278dn%40chromium.org?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/1ea53041-4075-4361-903c-a471055d0e8en%40chromium.org.
