Bug 283803 – Inconsistent Behaviour of `navigator.permissions` API on Safari iOS

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKit Misc.

I'm working on implementing a PWA and I noticed a few issues that are specific to Safari, and more so to Safari on iOS (https://developer.apple.com/forums/thread/769794). One of those is that the `navigator.permissions` API misbehaves in two ways:

1. On iOS (but apparently not on desktop), `navigator.permissions.query({ name: 'notifications' })` always returns 'prompt' regardless of the actual permission value, and even if the notification permission was requested in that same session. However, `Notification.permission` does return the correct value. This behaviour is inconsistent with other browsers, that return consistent values no matter how permissions are queried.
2. Perhaps related to the first issue: a `change` listener on the permissions result object form `navigator.permissions.query` never gets triggered.

I've created a simple HTML app to demonstrate this issue, which I attached.

Created attachment 473391 [details]
Simple PWA demonstrating permission query issue

Created attachment 473392 [details]
Required companion manifest file

[Radar WebKit Bug Importer]

<rdar://problem/140860946>

[Radar WebKit Bug Importer]

<rdar://problem/140860970>

[Ben Nham]

(1) definitely doesn't seem correct and we will take a look.
(2) definitely does not work on iOS or macOS (at least not in most cases) based on the way the integration with the system's notification framework works.

[Radar WebKit Bug Importer]

<rdar://problem/140861191>

> (1) definitely doesn't seem correct and we will take a look.

That'd be great. Thanks!

> (2) definitely does not work on iOS or macOS (at least not in most cases) based on the way the integration with the system's notification framework works.

If this can't be fixed, is there a way to at least feature detect it? The change listener is useful to react to preference changes (and a fallback is periodically checking `Notification.permission`, but we don't fall back if `navigator.permission.query` is available)

[Ben Nham]

The first issue with Notification.permission not matching Permissions.query should be fixed in iOS 18.2, specifically by bug 277656. I'm going to dup this bug to that one. Please verify that this is correct if you have access to an iOS 18.2 device.

The basic issue is that the way Permissions.query works is that it calls back to the embedder (via `-[WKWebView _webView:queryPermission:forOrigin:completionHandler:]`). In this case, the embedder is Web.app, which is the iOS system app that hosts home screen web apps. I looked at their delegate callback and it did not handle the push or notifications permission at all, so that API was returning the default value of prompt.

The usual way to fix this would be to fix the embedder's implementation of the delegate callback. But in this case, for iOS 18.2, we moved management of the push and notifications permission out of the embedder and in to a WebKit daemon in bug 277656. So now this just works without any changes to the embedder.

As for making change notifications work for this permission type, I don't see a particularly great way of expressing that this support doesn't exist via feature detection without potentially causing breakage. For instance, nulling out onchange for the PermissionStatus object associated with push/notifications permissions might cause some apps to start crashing unexpectedly.

We should still have a bug that tracks making that feature work, so I've filed a bug tracking that issue here: https://bugs.webkit.org/show_bug.cgi?id=285457. It is currently blocked on a system-level feature request for the UserNotifications framework for that framework to actually tell us that the permission status change (which is a bug we were actually already tracking internally for perf/power optimization purposes).

*** This bug has been marked as a duplicate of bug 277656 ***