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

Bug #1371166 reported by Alexander Sack on 2014-09-18
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Oxide
Critical
Olivier Tilloy
1.2
Critical
Olivier Tilloy
qtubuntu-sensors
Critical
Olivier Tilloy
webbrowser-app
Invalid
Critical
Unassigned
qtubuntu-sensors (Ubuntu)
Undecided
Olivier Tilloy

Bug Description

On my N4 I can use our HERE provider to get a location fix using latest utopic image. I cannot get this to work in any browser maps (e.g. here.com maps.google.com etc.).

Filing this bug to have this on our radar.

Related branches

Alexander Sack (asac) on 2014-09-18
summary: - location does not work in browser, but works in osmtouch
+ HERE location does not work in browser, but works in osmtouch
Changed in webbrowser-app:
importance: Undecided → Critical
tags: added: rtm14
Olivier Tilloy (osomon) wrote :

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.

Changed in qtubuntu-sensors:
assignee: nobody → Thomas Voß (thomas-voss)
Changed in oxide:
assignee: nobody → Olivier Tilloy (osomon)
Changed in webbrowser-app:
status: New → Invalid
Changed in qtubuntu-sensors:
importance: Undecided → Critical
Changed in oxide:
importance: Undecided → Critical
Pat McGowan (pat-mcgowan) wrote :

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

Thomas Voß (thomas-voss) wrote :

@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.

tags: added: touch-2014-09-25
Thomas Voß (thomas-voss) wrote :

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.

Changed in qtubuntu-sensors:
status: New → Invalid
Thomas Voß (thomas-voss) wrote :

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

Olivier Tilloy (osomon) wrote :

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.

Changed in oxide:
status: New → Confirmed
Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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.

Changed in oxide:
status: Confirmed → In Progress
Olivier Tilloy (osomon) on 2014-09-23
Changed in qtubuntu-sensors:
assignee: Thomas Voß (thomas-voss) → Olivier Tilloy (osomon)
status: Invalid → In Progress
Olivier Tilloy (osomon) on 2014-09-24
Changed in oxide:
milestone: none → 1.2.2
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in qtubuntu-sensors (Ubuntu):
status: New → Confirmed
Olivier Tilloy (osomon) on 2014-09-24
Changed in qtubuntu-sensors (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Olivier Tilloy (osomon)
Changed in oxide:
milestone: 1.2.2 → branch-1.3
Launchpad Janitor (janitor) wrote :

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

Changed in qtubuntu-sensors (Ubuntu):
status: In Progress → Fix Released
Olivier Tilloy (osomon) on 2014-09-25
Changed in qtubuntu-sensors:
status: In Progress → Fix Released
Selene ToyKeeper (toykeeper) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.