Bug 275268
| Summary: | Geolocation permission state is not immediately reflected in the response of the permissions API, only after a page reload. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | smoser |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | cdumez, marcosc, rupin, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 17 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | macOS 14 | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=275479 https://bugs.webkit.org/show_bug.cgi?id=275950 |
||
smoser
I experimented with the permissions API WebKit implementation for geolocation on iOS and MacOS using [this testing site](https://permission.site/permission-status). I'm in particular interested in the behavior for “remembered” granted states. So I tried the following steps in MacOS:
1. Enable Location Services in settings
2. Enable Location Services for Safari in settings
3. Get a geolocation prompt
4. Tick the [Remember my decision for one day] checkbox
5. Click [Allow]
Expected behavior
1. `navigator.geolocation.getCurrentPosition(...)`, i.e. "Access Status" reports `SUCCESS`
2. `navigator.permissions.query({ name: 'geolocation' })`, i.e. "Permission Status" reports `GRANTED`
3. When I reload the page, the permission status now reports `GRANTED`
Observed behavior:
1. `navigator.geolocation.getCurrentPosition(...)`, i.e. "Access Status" reports `SUCCESS`
2. `navigator.permissions.query({ name: 'geolocation' })`, i.e. "Permission Status" still reports `PROMPT`
3. When I reload the page, the permission status now reports `GRANTED`
We want to provide a consistent end-to-end experience between content-area UI and browser-side UX. To do that, we need to understand how the browser UX will behave if (for example) we call the browser’s geolocation API -- will a permission prompt be shown? Or is the permission already granted or denied?
The permission API should return `GRANTED` if and only if getCurrentPosition() will not be blocked by permissions framework.
We can then adjust our content-area UI to tailor nicely with the browser-side UX, which is inferred from the returned permissions status from the `query()` API, and the associated semantics [outlined here](https://w3c.github.io/permissions/#permissions). For this reason, it is critical for us that we can rely, across all browsers, on the returning the fresh state, without necessitating reloads.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/129867643>
smoser
After some more testing, we found that this is only a limitation of the change event API outlined at https://developer.mozilla.org/en-US/docs/Web/API/PermissionStatus/change_event. The returned value from navigator.permissions.query behaves as expected.
rupin
Thank you for filling the bug! Yes, the Permissions API onchange event is not fully supported, so this is expected.
rupin
We are aware of this issue and so this bug should remain open/unresolved for now.