ubuntu-webapps-bugs team mailing list archive

[Thomas Voß <1359251@xxxxxxxxxxxxxxxxxx>]

The general flow of things is:

  webbrowser-app <-> qtlocation <-> Ubuntu backend <-> platform api <->
location service <-> trust store

The location service returns an error message if the user denied access,
see http://bazaar.launchpad.net/~phablet-team/location-
service/trunk/view/head:/src/location_service/com/ubuntu/location/service/skeleton.cpp#L172.
However, the error report is not correctly handed up the stack on the
client side. With that, I marked qtubuntu-sensors as affected, too.

** Also affects: qtubuntu-sensors
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to webbrowser-app.
https://bugs.launchpad.net/bugs/1359251

Title:
  [webapps] Denying geolocation permission doesn’t inform the requester
  of the denial

Status in Location Service:
  New
Status in Oxide Webview:
  New
Status in QT Ubuntu Sensors:
  New
Status in Web Browser App:
  New

Bug description:
  Since version 0.23+14.10.20140818-0ubuntu1 (more precisely, see
  http://bazaar.launchpad.net/~phablet-team/webbrowser-
  app/trunk/revision/672), webapps delegate the geolocation permission
  prompt to the trust store. This is implemented by initially accepting
  the request to allow it to go through and actually query the location
  service.

  If the user denies permission however, the location service doesn’t
  seem to inform oxide of the denial, and the page keeps waiting for a
  geolocation update until it eventually times out, instead of informing
  the user right away that geolocation is not available.

  This can easily be tested by running the following on a device:

      webapp-container --desktop_file_hint=/usr/share/applications
  /webbrowser-app.desktop http://html5demos.com/geo

  (make sure to wipe the trust store db in
  ~/.local/share/UbuntuLocationService/trust.db beforehand, to not use a
  cached answer).

  I’m not sure whether the problem is in the location service itself, or in oxide.
  Or is there a way for the webapp container to trigger and communicate with the trust store prompt?

To manage notifications about this bug go to:
https://bugs.launchpad.net/location-service/+bug/1359251/+subscriptions