[Webkit-unassigned] [Bug 257889] Permissions API reports wrong permissions for notifications

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=257889

--- Comment #5 from Sihui Liu <sihui_liu at apple.com> ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230616/50b63496/attachment.htm>