1515780 - Consider more aggressively throttling deviceorientation events

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, enhancement, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

See bug 1511731 comment 8. There's a profile there where we're spending a bunch of time servicing deviceorientation events, and that's causing page jank.

If we're not already throttling those events, we should consider it. If we're already throttling them, maybe we're not throttling them enough.

Comment 1

[Chris Peterson [:cpeterson]]

Adding [qf] whiteboard tag so the Performance team will review this bug.

Comment 3

[Makoto Kato [:m_kato]]

When I test bug 1217942's sample on Chrome today, sampling rate is changed on current Chrome version. But sampling rate seems to be 60fps on Chrome 76.

I guess that device orientation uses 60fps for sampling rate on Blink now?
https://cs.chromium.org/chromium/src/device/vr/orientation/orientation_device.cc?q=set_frequency&l=101&dr=C
https://cs.chromium.org/chromium/src/services/device/public/cpp/generic_sensor/sensor_traits.h?dr=C&g=0&l=14

Comment 4

[Makoto Kato [:m_kato]]

rbarker or snorp, do we still need use SENSOR_DELAY_FASTEST for some sensor types? Although we changed this value from SENSOR_DELAY_GAME to SENSOR_DELAY_FASTEST by bug 1217942, Chrome already changed to 60fps (according to https://caseyyee.github.io/DevicemotionTest/) . Since some sites listen deviceorientation event, this event handler is called a lot.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Makoto Kato [:m_kato] from comment #4)

rbarker or snorp, do we still need use SENSOR_DELAY_FASTEST for some sensor types? Although we changed this value from SENSOR_DELAY_GAME to SENSOR_DELAY_FASTEST by bug 1217942, Chrome already changed to 60fps (according to https://caseyyee.github.io/DevicemotionTest/) . Since some sites listen deviceorientation event, this event handler is called a lot.

Hmm, I guess if Chrome throttles them we can too. Do we care about the webvr polyfill anymore? Probably not?

Comment 6

[Tom Ritter [:tjr]]

Adding fresh telemetry to this thread, plus a fingerprinting-side motivation that I don't think was on the table when this was filed in 2018.

How big is the population on the fast path?

user_characteristics ping, release channel, 2026-03-01..2026-04-20, deduplicated per client_identifier. Of 26.6M Firefox clients:

• ~9.2M Android clients report a non-zero motion_decimals (i.e. received at least one devicemotion sample in the 10 s collection window). That's 99.2 % of Android Firefox.
• motion_freq (events ÷ elapsed-seconds, rounded) within that Android population:

dispatch rate	% of Android Firefox
> 100 Hz	68.8 %
> 10 Hz	87.2 %
≤ 10 Hz	12.8 %

The 87.2 % above 10 Hz is the population on the SENSOR_DELAY_FASTEST fast path Bug 1217942 added. The remaining 12.8 % are devices where the slowest of the three sensor types is itself ≤ 10 Hz (older chipsets, missing gyroscope so mLastRotationRate never populates inside the 100 ms window, power-save throttling). So the perf cost Mike profiled on dailymail.co.uk is essentially universal across Android Firefox.

The deviceorientation side is the same SOC-driven distribution — FireDOMOrientationEvent doesn't coalesce (single sensor → single event, no buffering needed), so every rotation-vector arrival becomes a DOM event immediately. ~8.3 M Android clients have non-zero orientation_decimals, and orientation_freq mirrors the motion distribution (~200 Hz cluster 49-59 %, ~100/125 Hz 24-27 %, low-rate tail 1-15 Hz, >260 Hz on flagship chipsets).

Fingerprinting motivation, which I don't think was discussed in this thread:

Beyond the page-perf issue this bug was filed for, the raw sensor rate is itself a passive fingerprinting axis. Per-SoC SENSOR_DELAY_FASTEST ranges from ~50 Hz on entry-level chipsets to >300 Hz on flagships, and tracks chipset generation closely.

Any cross-origin script that adds a devicemotion or deviceorientation listener picks this up passively, with no permission prompt on current Firefox (the W3C-spec'd permission gate is still open as Bug 1536382). So throttling the dispatch rate also collapses a real fingerprinting axis — the perf and privacy stakeholders want the same change.

Re: Jim Willcox's question from comment 5 ("Do we care about the webvr polyfill anymore?"):

I don't think so?

A couple of design options that preserve the WebVR-style use case while addressing both the perf and the fingerprinting cost:

1. Cap at 60 Hz (matching Chrome and the W3C spec recommendation of "no more than 60 times per second"). Keeps motion-driven VR-class use cases functional (60 fps is the typical VR display refresh), gives the perf relief Mike profiled, and reduces the per-SoC *_freq axis to near-zero entropy because nearly every Android sensor can produce ≥ 60 Hz. This is the natural answer to Kato's comment 3-4. Implementation is a real throttle in FireDOMMotionEvent and a new one in FireDOMOrientationEvent, not a removal of SENSOR_DELAY_FASTEST.
2. Permission-gate it (Bug 1536382), then leave the fast path for opt-in. Aligns with the W3C spec and iOS Safari's behavior since iOS 13. Users without a permission grant get nothing (or default values); users who opt in get the SENSOR_DELAY_FASTEST rate, preserving polyfill compat for the subset that actually uses it. This is the largest-leverage change because it also addresses the *_decimals fingerprinting axis (no events → no decimal-precision signature).
3. Both. 60 Hz cap by default + permission-gate for full-rate access. This is roughly what iOS Safari does and what Chrome's permission story has been moving toward.

Quantizing the values (round accel to 4 decimal places, orientation to 2) is an orthogonal change that addresses the *_decimals axis specifically; it doesn't help with *_freq and doesn't engage the WebVR trade-off, so it's a separate bug.

Comment 7

[Makoto Kato [:m_kato]]

Attachment: Bug 1515780 - Sensor's sampling rate should be 60Hz like Chrome. r=#geckoview-reviewers!

Currently GeckoView's sensor sampling rate is SENSOR_DELAY_FASTEST
(200Hz). This setting was for VR and game. But Chrome/Android uses 60Hz
for sensors. So This fix changes the sensor sampling rate to 60Hz like
Chrome.

Current value is too expensive for normal web browsing since some sites
uses this sensor data for screen size detection (Bug 2044630) or for
other purposes like Ads. So this change will reduce the power
consumption and improve the battery life.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/76cb05a0d829
https://hg.mozilla.org/integration/autoland/rev/9788d8f86b25
Sensor's sampling rate should be 60Hz like Chrome. r=geckoview-reviewers,ohall

Comment 10

[amarc]

https://hg.mozilla.org/mozilla-central/rev/9788d8f86b25