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

Bug #1359251 reported by Olivier Tilloy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Invalid
Undecided
Unassigned
location-service
Invalid
Undecided
Unassigned
qtubuntu-sensors
New
Undecided
Thomas Voß
webbrowser-app
Invalid
High
Unassigned

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?

David Barth (dbarth)
Changed in webbrowser-app:
importance: Undecided → High
tags: added: rtm14
Revision history for this message
Thomas Voß (thomas-voss) wrote :

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.

Olivier Tilloy (osomon)
Changed in qtubuntu-sensors:
assignee: nobody → Thomas Voß (thomas-voss)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Marking the oxide task as invalid for now. Please reopen if this is in error.

Changed in oxide:
status: New → Invalid
Thomas Strehl (strehl-t)
tags: added: touch-2014-09-25
Revision history for this message
Olivier Tilloy (osomon) wrote :

Marking the webbrowser-app task invalid too, as it appears the issue is contained in qtubuntu-sensors.
Once qtubuntu-sensors reports the denial correctly, oxide will pick it up, and webbrowser-app with it too.

Changed in webbrowser-app:
status: New → Invalid
Stephen M. Webb (bregma)
Changed in location-service:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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