Yeah, permission grants not counting as activation for autoplay seems wrong here, but I'm nervous about them counting in other contexts. If confirming a permission prompt allowed the site to open a popup, that seems wrong to me too.

Mustaq: can you confirm that this is desired behavior activation wise?

Able to reproduce this issue on Windows 10, Mac OS 10.13.6 and Ubuntu 14.04 on the latest Stable 71.0.3578.80 and latest Canary 73.0.3632.0.

Bisect Information:
====================
Good Build: 71.0.3564.0
Bad Build : 71.0.3565.0

By running the per-revision bisect script, below is the Changelog URL.
https://chromium.googlesource.com/chromium/src/+log/479cc17585a64910853e9949b053499ecbeca9a5..b469a6e8b042ebeb028c7f601f7c98990981b9a7

From the above Changelog, suspecting the below Change.
Reviewed-on:  https://chromium-review.googlesource.com/1225650

csharrison@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.
Adding 'ReleaseBlock-Stable' for M-71 as this is a recent regression. Please feel free to remove if it is not applicable.

Thanks...

I don't think this needs to block a release. The behavior here (permission grants not causing user activation) is not a regression AFAIK, and other forms of autoplay were likely always affected.

+mlamouri FYI

I understand that it's up to the Speech API owners to decide how this is supposed to work.

But from user activation perspective, a click on permission dialog should never be treated the same as click on webpage.  I don't think we can expect any user interaction for a page when the user really interacted with the browser.  To see why this is bad, consider multiple tabs open from the same site, with one never got focus so far (may be a newly 'window.open()'ed tab with a malicious purpose). It would be unacceptable if the background (unfocused) tab can start recording just because the foreground tab asked for recording permission for the site (even though it's fine that the permission applies to all same-site tabs).

Mustaq: I think your example is not exactly what I was thinking. You described a clicking a permission prompt on one tab causing a _different_ tab to be able to record.

If permission prompt clicks are just considered activation for the tab they overlay over, this wouldn't work.

+dmazzoni

csharrison@: You are correct about "the tab they overlay".  May be my comments were too strong.

But any interaction with the permission dialog is with the browser, so my concern remains.  Let me try another scenario, hopefully it will stick.

A malicious page could ask for permissions to be able to do something different.  E.g. we can modify the repro here in a way that once the page detects at onload that it has recording permission (granted from a previous onload), it can ask for a different permission and then start recording, right? 
 We can argue that the page can always add a fake button "click here to change color" then start recording but here the user is trusting the page's button while with permission dialog the user trusts a browser button.

---

Also note that if a page expects to start recording without any interaction on it (like the repro here), and it won't work next time the page is loaded after the permission is granted: the permission was granted before so there won't be any dialog at future onload events.  So the original scenario here is not very useful.

Yes agreed. Another point: denying a permission should probably never trigger activation.

This is leading me to think that what is really wanted here is a notion that granting microphone permission in particular should allow speech autoplay. This has strange predictability concerns (suddenly web developers must maintain a mapping of permission grants --> activation state), so I'm inclined to WontFix. dmazzoni, WDYT?

Great, WontFix will keep my app broken.  

If you allow permission (prompted per application / page), it should be considered activation.  If you deny, it should not be considered activation.

Autoplay is allowed if the page is using the microphone or the camera. Allowing autoplay on permission grant isn't helping anyone because at the next visit the user wouldn't be prompted again and the problem would come back.

I believe this should be WontFix.

If the user approved the permission once, it should continue working on additional page loads.   It should be considered activation because it's the page prompting for the permission that the user must accept.  The user is interacting with the page.  It's activation.

After recording permission is granted, subsequent page loads won't show any permission dialog, so there will be no user interaction around onload.  No interaction => no recording.

Note that a granted permission here means "the page can use recording", it doesn't mean "the page can use recording w/o user activation".  Sorry, we can't relax that.

That's fine.  Clearly there's no common sense left at Google anyways since very few people actually wanted this change (read the comments on your own announcement page https://developers.google.com/web/updates/2017/09/autoplay-policy-changes)

Oh well, thanks for nothing.  

The visibly impaired thank you from all over the world.  The idea was for them to be able to use voice to text and text to voice... might be hard for them to trigger a "user activation" now.