Many bugs introduced in Safari push notifications

• Component: New Bugs
• Status: RESOLVED INVALID

In the last version of Safari (12.1) you have introduced many bugs related to push notifications. I contact you from Pushpad, since you have broken thousands of website without any previous notice. 

1. Calling "window.safari.pushNotification.requestPermission" on page load now throws an exception:
"Unhandled Promise Rejection: Push notification prompting can only be done from a user gesture."

This is something that *breaks most websites*. 

Also this is something that should be discussed publicly, it is not something that you can change during the night, without any previous notice. Your behavior is unprofessional and not respectful towards developers that have built large SDKs upon your APIs. 

Moreover this change will not improve the UX since most websites will start using 2 step prompts as described here:
https://github.com/wicg/interventions/issues/49

Also note that there is a reason if Google, Mozilla, etc. still allow the notification prompt on page load: this issue still needs further discussion to find the right solutions. You can't simply break the existing APIs. You can't simply ignore that, after this change, websites will start using 2 step prompts and floating widgets, which offer an even worse UX.

2. Even worse, when you now call "window.safari.pushNotification.permission()" to check if the permission already exists, you get "undefined" (from the console) or the code stops executing. This is a bug in any case, because we are not displaying a prompt to the user here. Probably this happens if you have previously called requestPermission and the promise is rejected: requestPermission leaves the permission in an inconsistent state.

This means for example that you are also breaking the following:
a. the user allows notifications after an interaction with the page
b. after some time, on another page, you need to get the subscription details on page load, for example because you want to send the subscription to the server with some new tags
c. when you call "window.safari.pushNotification.permission()" or "window.safari.pushNotification.requestPermission" to simply get the existing subscription it doesn't work


Please consider reverting this changes (at least until a better alternative is found).

Also note that Chrome already tried to introduce the requirement of user gestures for the prompt and then this was removed (from v37) because it didn't made sense: https://bugs.chromium.org/p/chromium/issues/detail?id=274284#c45 So, if Chrome has removed this restriction and you have never had this restriction, why are you introducing it now (breaking most applications)?

My request is to revert this changes completely. However if you really want to keep something, at least make it compatible with the existing websites and SDKs. In particular:

1. DO NOT RAISE AN EXCEPTION when you need to display the prompt on page load. Instead of raising the exception you can simply minify the prompt: for example you can display a notification icon in the address bar that the user can click in order to allow notifications (as discussed here: https://discourse.wicg.io/t/require-user-gesture-for-notification-permission-request/2366/6)

2. DO NOT RAISE AN EXCEPTION if you call window.safari.pushNotification.requestPermission() and the permission is already GRANTED. It doesn't make sense to break this call now (v12.1), since it doesn't even show a prompt to the user.

[Alexey Proskuryakov]

Thank you for the report! Safari push notifications are a Safari feature, not a WebKit one, so we cannot track it here.

Tracked internally by Apple in rdar://problem/49340787.

See also: https://webkit.org/blog/8406/release-notes-for-safari-technology-preview-64/

If this is not the right place, could you suggest where I can post this issue?(In reply to Alexey Proskuryakov from comment #3)
> Thank you for the report! Safari push notifications are a Safari feature,
> not a WebKit one, so we cannot track it here.
> 
> Tracked internally by Apple in rdar://problem/49340787.
> 
> See also:
> https://webkit.org/blog/8406/release-notes-for-safari-technology-preview-64/


If this is not the right place, could you suggest where I can post this issue?

[Alexey Proskuryakov]

Your Apple report is in the right place, rdar://problem/49340787.