Cross-origin notification permission returns denied for default state
Reported by
ja...@onesignal.com,
Sep 15 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.18 Safari/537.36 Steps to reproduce the problem: On Chrome 62+ (currently in Beta), accessing a cross-origin iframe's notification permission returns "denied" if the actual permission is "default" (where default means the user has neither granted nor denied permissions). Demo: https://jsfiddle.net/ok7nqjyj/7/ ---------------------------------------------------------------- This affects sites that subscribe the user to a different origin than the user is viewing if the site queries the subscribing origin's permission before deciding to prompt. With the above behavior, new (never subscribed) users cannot be identified; only those who have already blocked or granted notification permissions can be identified. Example: AMP Web Push Visitors view AMP pages on Google's origin, but subscribe to the canonical origin through a popup. To provide a better user experience, AMP web push defaults to hiding subscription options if the canonical origin's notification permission is blocked. The permission is detected by opening an iframe to the canonical origin and calling Notification.permission from within the iframe. Some inconsistencies we found are: a) Geolocation default permission is still accessible. b) The push permission (PushManager.permissionState) returns the correct permission state, but it requires an active service worker registration to use. A service worker registration may not exist; a user may have blocked permissions and cleared their service worker registration. What is the expected behavior? What went wrong? . Did this work before? N/A Does this work in other browsers? N/A Chrome version: 62.0.3202.18 Channel: beta OS Version: OS X 10.11.6 Flash Version:
,
Sep 15 2017
Functions that check the current permission status should return whatever the function to *request* permission is going to return when no action has been taken. Since Notification.requestPermission() and co. will return DENIED now that we don't allow requesting permission from iframes anymore, we decided that Notification.permission should also indicate DENIED.
,
Sep 15 2017
This is the right thing to do WRT to the Permissions API at least: permission status should return what will happen if the website tries to use/request the feature. The same behaviour applies when checking permission from an insecure origin when the feature can't be used in them. This seems to be WAI.
,
Sep 15 2017
,
Sep 18 2017
raymes - this could be important if it is a bug, but sounds like it isn't. Can you make the final call?
,
Sep 18 2017
I agree with #2 and #3 that this is WAI. It would still be useful to be able to determine the permission state in a top level origin, but this is something that we should consider extending the API to make possible (tracked in issue 751857). > a) Geolocation default permission is still accessible. Geolocation can currently still be requested from iframes, so this is consistent. > b) The push permission (PushManager.permissionState) returns the correct permission state This is inconsistent and should be fixed. Permission can't be requested from the SW so denied should also be returned here, unless permission has been granted. This is tracked in issue 751857 also. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by owe...@chromium.org
, Sep 15 2017Status: Available (was: Unconfirmed)