Re: Device Orientation specification co-editor

>
> >
>> > Another issue we have is with capability detection, especially on
>> excluding
>> > PC browsers.
>> >
>> > Many PC browsers have the window.DeviceOrientationEvent function
>> > defined...yet never ever return a deviceorientation event. e.g. this
>> code
>> > registers a listener that never gets called...so we are left falling
>> back to
>> > some sort of timeout based assumption 8/
>> >
>> > if (!!window.DeviceOrientationEvent) {
>> >   window.removeEventListener('deviceorientation', function() {
>> >     // clearly supported
>> >   }, true);
>> >   // not clear at all until deviceorientation event called or some
>> timeout
>> > occurs 8(
>> > } else {
>> >   // clearly not supported
>> > }
>> >
>> > This is the same for both DeviceOrientation and DeviceMotion.
>> >
>> > Having browsers NOT implement window.DeviceOrientationEvent unless they
>> > truly do support it would be best. But I'm open to discussion of other
>> > options or tips on how we could code around this more effectively.
>>
>> Would the following addition to the specification suffice here?
>>
>> "When support for a feature is disabled (e.g. as an emergency measure
>> to mitigate a security problem, or to aid in development, or for
>> performance reasons), user agents must act as if they had no support
>> for the feature whatsoever, and as if the feature was not mentioned in
>> this specification. For example, if a particular feature is accessed
>> via an attribute in a Web IDL interface, the attribute itself would be
>> omitted from the objects that implement that interface - leaving the
>> attribute on the object but making it return null or throw an
>> exception is insufficient."
>>
>> Of course, this would be entirely dependent on implementers following
>> this requirement.
>>
>
> At least in Chrome/Chromium there is an implementation snag in hiding APIs
> this way. It requires sniffing e.g. sensor presence or permissions and then
> communicating that cross process, at page startup time. This is a blocking
> process, to avoid (not) exposing the API incorrectly for some time. It's a
> speed bump.
>
> Perhaps we have a good solution for this now, it's worth checking.
>

Just to clarify on the feature detection issue: currently in Chrome the
Device Orientation API is implemented in a non-blocking way to avoid jank
while loading web pages. So there is no way of knowing whether the sensors
are available before receiving a callback. The problem with timeouts is
that it is not clear what the timeout value should be, as it tends to
depend on the underlying hardware. Therefore according to the specification
an all-null event is fired if sensors are not available.