- From: Rob Manson <roBman@buildAR.com>
- Date: Mon, 24 Mar 2014 16:17:39 +1100
- To: Tim Volodine <timvolodine@google.com>, Michael van Ouwerkerk <mvanouwerkerk@google.com>
- CC: Rich Tibbett <richt@opera.com>, public-geolocation <public-geolocation@w3.org>
Hey Tim,
sorry for the slow reply...been very sidetracked with some other things.
> 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.
So based on this comment shouldn't the following code fire the event but
return the all-null values as defined in the spec?
window.addEventListener('load', function() {
window.addEventListener('deviceorientation', function(e) {
alert(e); // this should fire once ASAP with all-nulls
}, true);
}, true);
This isn't the case with the latest Chrome (or Firefox) on PCs and it
never fires. This is the scenario that's causing us the most grief and
requiring this hacky timeout 8/
roBman
Received on Monday, 24 March 2014 05:18:07 UTC