Skip to content

Allow firing pushsubscriptionchange on all permission changes #400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from
Open

Allow firing pushsubscriptionchange on all permission changes #400

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -342,6 +342,22 @@ <h2>
`{name: "push", userVisibleOnly: false}` is [=PermissionDescriptor/stronger than=]
`{name: "push", userVisibleOnly: true}`.
</p>
<p>
When the permission state changes (for example, it is revoked or re-granted), the <a>user
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably use the revocation hook: https://w3c.github.io/permissions/#dfn-permission-revocation-algorithm

Would be nice if we can decide whether this should be on revocation, regranted, or both.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a note below, clarifying why it can make sense to leave this up to the implementor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This comment is not about the note though)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And maybe also worth getting feedback from Permisssion API people about whether it's a good idea to fire at regrant at all. I think probably there's a reason why there's no event for permission change?

cc @Trikolon

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is why I didn't close the thread. I'm not sure how it looks to hook into the revocation algorithm for revocation while leaving the same wording for re-granting, so I would leave this open and wait for others' opinions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'm told that @bakulf would know better about permission API, so redirecting the question to him.)

agent</a> MAY <a>fire the "`pushsubscriptionchange`" event</a> for subscriptions created
with that permission, with the <a>service worker registration</a> associated with
the <a>push subscription</a> as |registration|, a {{PushSubscription}} instance
representing the <a>push subscription</a> which should not be used anymore (for example,
because it has been or it is being <a>deactivated</a>) or `null` if it is not available
anymore as |oldSubscription|, and a {{PushSubscription}} representing a new valid <a>push
subscription</a> or `null` if none could be created as |newSubscription|.
</p>
<p class="note">
A permission state change can happen for a number of reasons, some of which are likely
vendor specific. Because of that, this specification does not mandate firing the
<a>pushsubscriptionchange</a> event in all possible cases, and instead leaves it up to
the <a>user agent</a> to decide when it is appropriate to do so.
</p>
</section>
</section>
<section>
Expand Down