ampproject / ampproject/amphtml

push notification subscriptions on main page

Open
#34,566 7 comments 2 reactions 0 assignees View on GitHub
P2: Soon Type: Feature Request WG: components
Dominant language
JavaScript
Stars
14.9k
Forks
4.1k
PR merge metrics
No merged PRs in 30d

Description

### Description

The current `` [implementation ](https://amp.dev/documentation/examples/components/amp-web-push/) 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
- https://cdn.onesignal.com/sdks/amp/amp-helper-frame.js and
- https://cdn.onesignal.com/sdks/amp/amp-permission-dialog.js

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](https://amp.dev/documentation/examples/components/amp-web-push/):
```
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](https://developers.google.com/amp/cache/overview) e.g: [pub-com.cdn.ampproject.org](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
- [Intent to implement](https://github.com/ampproject/amphtml/issues/8791)
- [AMP Web Push PR](https://github.com/ampproject/amphtml/pull/10468)
- [Design doc](https://docs.google.com/document/d/15VBR9Ht373TW0KwYD5RUGfafX4nELbP-6uWj7ngIRWU/edit#heading=h.zha4avn54it8)

### 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](https://github.com/ampproject/amphtml/issues/34564)).

### Additional Context

## References
- [Intent to implement](https://github.com/ampproject/amphtml/issues/8791)
- [AMP Web Push PR](https://github.com/ampproject/amphtml/pull/10468)
- [Design doc](https://docs.google.com/document/d/15VBR9Ht373TW0KwYD5RUGfafX4nELbP-6uWj7ngIRWU/edit#heading=h.zha4avn54it8)

Contributor guide

Open the contributing guide

Research direction

Start by reading the amp-web-push implementation and the referenced amp-helper-frame.js and amp-permission-dialog.js scripts, along with the linked design and implementation discussions. Clarify how subscriptions should differ for AMP Cache and non-cache pages, then define the tests and user-visible behavior that would demonstrate main-page subscription is complete.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.