push notification subscriptions on main page

rgomezp commented 3 years ago

Description

The current <amp-web-push> implementation requires two script attributes 1) helper-iframe-url and 2) permission-dialog-url that I believe could be streamlined into either a single script or none at all. It all boils down to the following:

Proposal: the ability to subscribe to push notifications directly on the main page.

From my understanding, the reason (see below reference) for the two attributes listed above is due to AMP's restrictions on 3rd party synchronous scripts. I believe @jasonpang and others' original intentions were to load our (OneSignal) SDK in one of those scripts. However, from what I can see in

our SDK's only entry point (and thus access to subscription data such as push token, status, etc....) is via the service worker. If that is the case, then I don't really see a benefit to having a standardized script that communicates via iframe to subscribe the user.

The above scripts look the same as those in the official AMP setup instructions:

helper-iframe-url="https://amp.dev/documentation/examples/components/amp-web-push/amp-web-push-helper-frame.html"
permission-dialog-url="https://amp.dev/documentation/examples/components/amp-web-push/amp-web-push-permission-dialog.html"

I suspect that in the majority of cases, people are simply using these scripts as-is rather than customizing them and loading other synchronous JS.

So in essence, if it is mostly standardized now, why not standardize a way to subscribe to push directly on the main page?

Update: the reason that @jasonpang and the original implementors went with the iframe solution was because some pages are hosted in the AMP cache e.g: pub-com.cdn.ampproject.org.

But for those NOT using the amp cache, it would be a much better user experience if they could accept the native permission on the main site.

References

Alternatives Considered

The alternative is to leave things as they are -- with users subscribing via an iframe & popup window with a prompting mechanism (that doesn't work in Firefox).

Additional Context

References

mangesh commented 3 years ago

Are we planning to implement this?

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

rgomezp commented 1 year ago

Please do not close!

erwinmombay commented 1 year ago

ill keep this open and will triage if it is something we'd like to support

jkasten2 commented 1 year ago

Chrome's Storage Partitioning introduces a new problem, since <amp-web-push> uses an iframe. If site owner has an AMP page hosted on a Google domain (such as mysite.cdn.ampproject.org). However only if the end-user visits both your site directly (example, mysite.com) and a your AMP page on a Google domain (such as mysite.cdn.ampproject.org) at some point.

This creates an issue where it's possible to be subscribed a 2nd time on the same domain (mysite.com), as even Service Workers are also part of the Chrome Storage Partitioning. Example:

End-user visits mysite.com
End-user accepts notification permission and is subscribed for push notifications.
End-user visits mysite.cdn.ampproject.org
The mysite.cdn.ampproject.org page thinks the user is not subscribe for push notifications, when they actually are.
I believe (not tested) the end-user could subscribe again (even for the same domain, you can have 2 sandbox service workers).
If the site sends a push to all devices, I believe the end-user would see two notifications, since there would be two valid push endpoints and 2 service worker instances.

ampproject / amphtml