HERE location does not work in browser, but works in osmtouch

I’ve spent most of my day testing this, trying to reproduce failures, and the results are not consistent from one test run to the other (i.e. it sometimes works, sometimes not). By instrumenting oxide and qtubuntu-sensors though, I was able to determine that oxide calls in to the positioning plugin as expected, but the plugin does not always answer.

It’s likely that google maps and here.com issue a call to navigator.geolocation.getCurrentPosition() with a timeout parameter, so if the plugin takes too long to answer (or never does), the timeout is hit and the pages report that they were unable to determine the location. For comparison, http://html5demos.com/geo does not specify a timeout, so it sits there waiting for an answer forever (and sometimes eventually gets it, sometimes not).

The bug is not in webbrowser-app, and unlikely to be in oxide either, but I’m not sure where to target it.

This is a known issue for Loic and Thomas in how qtlocation is working aiui with fixes in progress

@Pat: Unfortunately not. The branches which are currently in flight are fixing the timeout issue for requestUpdate(int timeout = 0) for apps that use QtLocation (e.g., OsmTouch). However, web pages apparently just start updates and maintain their own timeout that we have no way of interfering with. That being said: We have to be fast enough.

Okay, one more data point: I instrumented qtubuntu-sensors, started the browser from the command line and observed output from qtubuntu-sensors. Location updates are definitely arriving in the browser and are propagated further on to oxide. Please see attached screenshot.

Cross-referencing a bug report, seems like the chromium (and with that, probably the oxide) geolocation stack is subject to instabilities:

  https://code.google.com/p/chromium/issues/detail?id=175909

I’m finally able to observe the same thing as Thomas: qtubuntu-sensors gets a position update, it notifies the oxide LocationProvider, which calls into content::LocationProviderBase::NotifyCallback(…) (see https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/geolocation/location_provider_base.cc&sq=package:chromium&rcl=1411411269&l=15, I verified that callback_ is not null), but this never seems to make it back to the caller.

To add to the above comment, this seems to be a bug in chromium itself, not the oxide layer. Not sure whether it’s https://code.google.com/p/chromium/issues/detail?id=175909 or something else though.

Ok, I think I know what’s going on: qtubuntu-sensors provides position updates with a horizontal accuracy set, but it’s set to something that’s not a number (NaN). According to QGeoPositionInfo’s documentation, if an attribute is not set, querying its value will return NaN. But in that specific case the attribute is set, so I think it’s reasonable to expect the value is a valid number. It looks like qtubuntu-sensors could be patched to ensure it’s not setting invalid values on attributes. oxide can also be patched to test the attributes and discard those that are not valid numbers.

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package qtubuntu-sensors - 0.6+14.10.20140924-0ubuntu1

---------------
qtubuntu-sensors (0.6+14.10.20140924-0ubuntu1) utopic; urgency=low

  [ Olivier Tilloy ]
  * Shield position updates against NaN values for horizontal and
    vertical accuracy. (LP: #1371166)
 -- Ubuntu daily release <email address hidden> Wed, 24 Sep 2014 17:13:51 +0000

Wow, first time I've ever seen location work on a krillin.