Bug 257889

Summary:	Permissions API reports wrong permissions for notifications
Product:	WebKit	Reporter:	cj
Component:	WebKit Misc.	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	cdumez, sihui_liu, webkit-bug-importer, youennf
Priority:	P2	Keywords:	InRadar
Version:	Safari 16
Hardware:	All
OS:	macOS 13
See Also:	https://bugs.webkit.org/show_bug.cgi?id=257710

Description cj 2023-06-09 08:25:12 PDT

# 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

Comment 1 Radar WebKit Bug Importer 2023-06-16 08:26:14 PDT

<rdar://problem/110901531>

Comment 2 Chris Dumez 2023-06-16 08:27:21 PDT

cc @youenn. I believe this behavior was intentional to avoid fingerprinting.

Comment 3 Sihui Liu 2023-06-16 09:11:30 PDT

(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.

Comment 4 cj 2023-06-16 12:03:59 PDT

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?

Comment 5 Sihui Liu 2023-06-16 13:16:37 PDT

(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).