v150 · Device Orientation

DeviceOrientation Events permission request API

Two static methods — DeviceOrientationEvent.requestPermission() and DeviceMotionEvent.requestPermission() — let a page explicitly ask the user to share orientation and motion sensor data. Each returns a promise resolving to "granted" or "denied". WebKit currently ships this API on iOS; Chrome now adopts it, so the same capability-detected code path works across browsers.

concepts

  1. Orientation permission & tilt

    Tap to call DeviceOrientationEvent.requestPermission() from a user gesture, then subscribe to deviceorientation and visualise live alpha/beta/gamma on a tilting card and a spirit level. Honest about desktops: the permission may grant, but with no orientation sensor there's simply no data.

  2. Motion permission & shake

    Call DeviceMotionEvent.requestPermission(), then read devicemotion: acceleration (with and without gravity) and rotation rate. A live magnitude meter and a shake detector that fires when total acceleration crosses a threshold.

  3. Feature-detect the gate

    The correct cross-browser pattern: requestPermission is a function on iOS Safari and now Chrome-with-the-flag, but absent elsewhere — where you may just addEventListener directly. This probe reports what your browser exposes and generates the exact progressive-enhancement snippet to copy.

why it shipped

Orientation and motion events can fingerprint a device and, in the wrong hands, infer keystrokes or physical activity — so exposing them silently is a privacy problem. WebKit on iOS gates the events behind an explicit, user-gesture-triggered requestPermission() call. Chrome historically delivered the events without that prompt on secure contexts, which meant developers had to branch: call requestPermission() if it exists, otherwise attach listeners directly. By adopting the same static methods, Chrome lets one capability-detected path work across implementations and gives users an explicit consent moment before sensor data flows.

enabling it

Rolling out: behind a flag in Chrome 150 (developer trial per the milestone listing); the Chrome 151 milestone listing records Enabled by default, and the feature detail (chromestatus API, updated 2026-07-15) gives desktop 151 with status text “In development” and an active “Prepare to ship” stage. Launch Chrome with --enable-blink-features=DeviceOrientationRequestPermission, or enable chrome://flags/#enable-experimental-web-platform-features. Requires a secure context and transient user activation — call it from a click/tap handler, or the promise rejects with NotAllowedError. These demos need a device with real orientation/motion sensors — a phone or tablet — and clearly label the no-sensor state on desktops rather than faking readings.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗