257889 2023-06-09 08:25:12 -0700 Permissions API reports wrong permissions for notifications 2023-06-16 13:16:37 -0700 1 1 1 Unclassified WebKit WebKit Misc. Safari 16 All macOS 13 NEW https://bugs.webkit.org/show_bug.cgi?id=257710 InRadar P2 Normal --- 1 cj webkit-unassigned cdumez sihui_liu webkit-bug-importer youennf oldest_to_newest 1960739 0 cj 2023-06-09 08:25:12 -0700 # Overview After denying permission status for notifications, leaving the site, and returning to the site the Permissions API (and window["Notifications"].permission) incorrectly reports that the visitor is not in Deny status. # Steps to Reproduce: * Visit: https://web-push-book.gauntface.com/demos/notification-examples/ * Click the switch to prompt for enabling push notifications * Choose to deny notifications * Close the browser tab * Open a new tab and re-visit https://web-push-book.gauntface.com/demos/notification-examples/ * In console run: ** `window["Notification"].permission` - reports "default" when should be "denied" ** `navigator.permissions.query({name: "notifications"}).then(p => { console.log(p.state) })` - reports "prompt" when should be "denied" * Note that in Safari Preferences -> Websites -> Notifications that "Deny" is shown for web-push-book.gauntface.com # Expected Results: The permission status should properly report that the visitor's notification permission is in Deny status # Actual Results: The permission status reports that visitor's notification permission is in a promptable state / not in Deny status # Version Information: Safari browser version: 16.6 Operating system: macOS Ventura 13.5 # Additional Information: Likely related to: https://bugs.webkit.org/show_bug.cgi?id=257710 1962101 1 webkit-bug-importer 2023-06-16 08:26:14 -0700 <rdar://problem/110901531> 1962103 2 cdumez 2023-06-16 08:27:21 -0700 cc @youenn. I believe this behavior was intentional to avoid fingerprinting. 1962120 3 sihui_liu 2023-06-16 09:11:30 -0700 (In reply to Chris Dumez from comment #2) > cc @youenn. I believe this behavior was intentional to avoid fingerprinting. Yes, this is intentional. In current implementation, if the site has not requested permission before (`Notification.requestPermission()`) in the page, we will not return real permission state. 1962150 4 cj 2023-06-16 12:03:59 -0700 To be clear, I am not talking about `Notification.requestPermission()` in this scenario. I am talking about the Permissions API. If this is indeed the intended behavior, how do you suggest that we are able to get the current permission status of a visitor to show relevant on-page elements? For example, a site may have a page where the visitor can "Click here to subscribe" or "Click here to unsusbcribe" but if we are unable to determine if the visitor is already in "deny" or "allow" status how can we programmatically display the proper messaging to the visitor? 1962158 5 sihui_liu 2023-06-16 13:16:37 -0700 (In reply to cj from comment #4) > To be clear, I am not talking about `Notification.requestPermission()` in > this scenario. I am talking about the Permissions API. In our current implementation, whether the web page has requested permission will affect the result of permission query. Specifically, if the per-site setting is "Ask" or "Allow", query() will return real value, i.e. "prompt" and "granted". If the per-site setting is "Deny", query() will return "prompt" until the page requests permission, which indicates the site wants to use the API, not just checking it for fingerprinting. If per-site setting is "Deny", `Notification.requestPermission()` will return "denied" without prompting user. > > If this is indeed the intended behavior, how do you suggest that we are able > to get the current permission status of a visitor to show relevant on-page > elements? > > For example, a site may have a page where the visitor can "Click here to > subscribe" or "Click here to unsusbcribe" but if we are unable to determine > if the visitor is already in "deny" or "allow" status how can we > programmatically display the proper messaging to the visitor? You will know "Allow" state. For "Deny", if query returns "prompt", you can just think of it as "Ask" and invoke Notification.requestPermission (or display the subscribe button; if user clicks on it, you will get `denied` and you could tell user notification must be turned on for this feature).