Closed Bug 1252657 Opened 8 years ago Closed 5 years ago

Selecting "Never Share Location" or "Block" requires a page refresh to update to "Always Ask" or "Allow"

Categories

(Core :: DOM: Geolocation, defect)

defect
Not set
normal

Tracking

()

RESOLVED INACTIVE
Tracking Status
firefox47 --- affected

People

(Reporter: jwilliams, Unassigned)

References

()

Details

(Whiteboard: btpp-followup-2016-03-08)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Tested on Aurora

https://www.google.com/maps?source=tldso

STR:
1. go to https://www.google.com/maps?source=tldso
2. click the location button (bottom left of screen)
3. select "Never Share Location"
4. click the lock (url bar)
5. select "Allow" (note location button is still inaccessible)
6. select "Always Ask" (note location button is still inaccessible)
7. refresh the page (note button is now accessible with "Always Ask" selected)

Expected:
Once "Allow" or "Always Ask" is selected in steps 5 & 6 the location button should be accessible.

Actual:
Once "Allow" or "Always Ask" is selected in steps 5 & 6 the location button is inaccessible.

This issue is persistent when e10s is enabled, disabled, and also with a clean profile.
I think this has been the same behavior for forever.

The problem is that changing the sites permission doesn't emit any kind of event the website could respond to. And until the permissions API (https://w3c.github.io/permissions/) is generally available, there isn't even a way for a website to ask if it is allowed to use geolocation. The only thing it can do is actually use navigator.geolocation and react to the success or error callback it gets. And in Firefox many permission choices don't trigger the error callback, so all the site is left with is waiting on a timeout.

In order for the website to react to changes in its permissions, it would have to continuously poll and try to use geolocation again and again without any direct user action to trigger this. If the user had selected "now now" at first, the user would get another permission prompt without a clear user action to trigger it, which is fairly confusing.

With the permission API in place, the website would still have to continuously check the permission and change the state of the "where am I" button accordingly. That doesn't strike me as the best way either, but would be workable today.

Marcos: Did the use-case of changing permissions while a website is displayed come up in the permissions API work? Do you think this is something that would be of more general use? I have a feeling that our work in Firefox to make the permission center more accessible and prominent might make it more likely for users to actually interact and change those permissions.
Flags: needinfo?(mcaceres)
Whiteboard: btpp-followup-2016-03-08
> Marcos: Did the use-case of changing permissions while a website is displayed come up in the permissions API work?

Yes, PermissionStatus is an event target (allowing to capture user rejections). And requestPermission() allows you to request a set of permissions. 

> Do you think this is something that would be of more general use?

Hopefully, but it does require work on making the permission center easy to find. 

> I have a feeling that our work in Firefox to make the permission center more accessible and prominent might make it more likely for users to actually interact and change those permissions.

Agree.
Flags: needinfo?(mcaceres)

I am thinking with the navigator.permissions.query API this is not likely still an issue.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.