+mustaq does User Activation v2 solve this? 

I don't know enough of the notification window to comment.  In particular, is the notification window runs in the same process and in the same frame hierarchy as the YouTube page?

Is there a repro I can test with?

Becca can you create a test page for mustaq?

Here is a repro:

1) Visit https://goroost.com/try-web-push
2) Allow the notifications permission prompt
3) Send a notification using https://videojs.github.io/autoplay-tests/plain/attr/autoplay.html
4) Click on the notification

Thanks for the repro, the problem is clear now.

I think user activation (gesture) should *not* propagate from notification window to the opened tab:

- Visiting a site by clicking on a notification doesn't feel different than visiting the site by clicking on a link.  Since the latter doesn't allow autoplay or popup, why should the former?

- The notification window seems to be running on a separate process from my limited observation, so it shouldn't be allowed to "copy" the activation state over to a renderer with which user hasn't interacted yet.

(And BTW, UAv2 doesn't "fix" it automatically.)

Thanks mustaq this is a good description and I agree with your characterization. Specifically, clicking on a notification is similar to any web link - it's not always clear to a user whether or not sound will play when they land on the new page. If it's a site where the user expects sound frequently then their MEI should allow autoplay, otherwise preventing it seems like the right approach to avoid surprises.

Closing issue as obsolete.

Closing the bug as per #c8.  Thanks johnpallett@.

Re: #7, I think there's an important distinction; for autoplay, we preserve gestures across navigation within the same domain.  So if you were on some video index/carousel page, and you click a particular video that links to player page, autoplay is enabled on that target page.

Since notifications are clearly labelled by domain, it feels like treatment should be consistent with links from that domain.  If the notification linked to a page that unexpected played video, it seems like the homepage for that site would be as likely to do the same.

Yeah, that's a fair distinction.

So, instead of allowing the general case, we want to allow "activation forwarding" to only same domain (or may be eTLD+1) pages, right?

As long as the domain of the notification is clear (which it appears to be in the notification examples I've seen) then I'm fine with activation forwarding.

Good point, let me clarify the domain question:

Is the notification domain always obvious to the users?

To me, an icon is not an obvious sign, but a text is as long as the UI makes it stand out.  But I think users can still be fooled by a prominent (bold, all caps etc) notification text saying "Site A wants to do blah blah" by a rouge site B.

For autoplay this probably isn't a huge security threat (which is why I'm fine with activation forwarding for that case) but I'm not sure about other APIs which might get enabled via user activation. Mustaq do you have thoughts on this?

There are ~30 different APIs that rely on user activation.  We want a guarantee that abusive sites can't use false notification text/icon to fool users into clicking the notification window so that the site can bypass popup blocker, for example.

Would it be a reasonable compromise to set the "has received gesture" bit but not mark it as currently activated? In other words, APIs that rely on the document being ever activated would be allowed and we should expect these APIs to be less security sensitive but more about user annoyance.

WDYT?