Add deviceorientation and devicemotion feature detection conformance requirement

[richtr]

We need a way to reliably check if DeviceOrientation and DeviceMotion events are supported in the current user agent.

This addition requires user agents not to expose window.DeviceOrientationEvent or window.DeviceMotionEvent interfaces if the respective sensors required by their events implementation is not available. That is to say, we would then be able to reliably check if these events are supported as follows:

if (window.DeviceOrientationEvent) {
  // current UA supports DeviceOrientation events. Register our 'deviceorientation' event listener here.
} else {
  // current UA does not support DeviceOrientation events. Provide fallback user controls here.
}

and:

if (window.DeviceMotionEvent) {
  // current UA supports DeviceMotion events. Register our 'devicemotion' event listener here.
} else {
  // current UA does not support DeviceMotion events. Provide fallback user controls here.
}

This is inline with conformance requirements used elsewhere in the web platform e.g. in the HTML specification (see the last paragraph of https://html.spec.whatwg.org/multipage/infrastructure.html#extensibility-2).

[mvano]

Are these meant to be absent if there are no sensors?

[richtr]

Are these meant to be absent if there are no sensors?

Yes. This is intended as an early signal that deviceorientation or devicemotion events are not supported or will only return null values once invoked.

[richtr]

We are having trouble in the three.js project to reliably determine whether DeviceOrientation Events are supported or not. See mrdoob/three.js#5338 (comment).

[mvano]

This is a synchronous API. This means (for Chrome) it must be known at renderer process startup time whether the sensor is available. This is in the critical path. How long does it take to perform this check for all sensors exposed in this manner?

[richtr]

Would it be possible to check for sensor support once during UA startup and then consult that result during all subsequent renderer process startups? That could even persist between UA startups thus making it a one-time only check.

[mvano]

Possibly. Just seems like something we'd want to check though, before making this a requirement :-)

[richtr]

There are many different ways to detect sensor support but that should remain out-of-scope of the specification itself. From this discussion it seems there are ways to keep this check off the critical rendering path in UAs.

Currently the best approach for a web developer to reliably detect device orientation/motion support is http://stackoverflow.com/a/21117224/320485. This is not a good situation as it delays the setup of sensor/fallback scene controls in web pages.

@mvano do you have any other ideas how we could improve device orientation/motion detection?

[mvano]

@richtr I'd suggest first measuring the implementation cost. Depending on the time it takes to measure presence of these sensors (and by extension, many sensors) decide whether a synchronous or an asynchronous API is most suitable. Synchronous is more developer friendly, but we don't want a specification to insist on that if it implies significant browser or renderer startup cost.

[mvano]

@richtr I might add, my concern about startup costs is also because most sites don't use this API, so they should not be slowed down because the browser implemented this API.

[richtr]

Perhaps the best alternative would be to remove deviceorientation and devicemotion event APIs from desktop UA builds? Most desktop-based browsers do not support these events but the APIs are made available on these platforms anyway. The only case I've come across where these events have been partially supported are on Macbook Pro laptops that include Sudden Motion Sensors. Even in these machines event support is limited since no magnetometer is available and thus no alpha values can be provided. I'm not sure whether partial spec implementations should be exposed.

[mvano]

That sounds feasible. Adding @beverloo @timvolodine @johnmellor @mounirlamouri as we've had this discussion internally about Battery, Vibration, Screen Orientation, and such. Opinions vary.

[anssiko]

The Generic Sensor API and its derived sensors https://www.w3.org/das/roadmap provide means to do feature detection in a robust manner without blocking the main thread, see https://w3c.github.io/sensors/#feature-detection

Proposal: close this PR, since the modern Generic Sensor-based APIs now provide the required hooks to do robust non-blocking feature detection.

Any concerns, please let us know.

(Note: there's a separate v2 issue w3c/sensors#7 for discussing sensor discovery of multiple sensors of the same type that has its own requirements re feature detection.)

[reillyeon]

Discussed at Devices and Sensors WG Face-to-face at TPAC 2018. Closing this issue as we are not adding new features that are not implemented by any vendor.