The existing code in question is AutoplayExperimentHelper::playMethodCalled, right?  That uses the same UserGestureIndicator logic as other gesture-triggered things in blink (eg. popups).

I'm in the process of making this more strict for touch -  issue 611981  (targeting M54).  Ideally this change would be done well in advance of that so that we have time to evaluate the compat impact of my change on WebAudio.

This bug has multiple steps:
- add UMA (see  bug 616807 )
- add warning
- add flag to toggle the restriction
- add way for developers to figure out this was blocked

Making this a OWP launch bug.

Does this require a spec change for WebAudio?  Currently, the spec says audio starts as soon as you've created an AudioContext.

I was writing this: https://github.com/WebAudio/web-audio-api/issues/836 :)

To give some context: Web Audio is used without a user gesture on Android quite often. We will break a lot of websites if we block this behaviour. Instead of blocking all Web Audio autoplay, we are going to do an intervention and block Cross origin iframes Web Audio autoplay.

Quick addendum: "will break a lot of websites" should be read "might break a lot of websites". The metrics are over representing breakage because a website creating an AudioContext outside of a user gesture handler would trigger a breakage recording even if when actually needed, the AudioContext would be set properly.

Though, the gist stays the same and we prefer to be on the safe side here.

Please just implement this as a muted state which automatically unmutes. See my comment here: https://github.com/WebAudio/web-audio-api/issues/836#issuecomment-245281938

Following Safari iOS behaviour has the benefit of helping with compatibility and also it helps developers to find out what's happening. Muting would entirely hide the behaviour to web developers.

You could expose a mute flag so developers have the option of delaying to the first gesture if they wish. I think this would help compatibility more, since there are no code changes required between desktop and mobile.

On mobile, websites that need Safari compatibility will already have to take into account this behaviour. If Chrome Android were to implement another behaviour, it wouldn't help compatibility.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b121dd8b9380574db8d6ebee851c1dfd61369cda

commit b121dd8b9380574db8d6ebee851c1dfd61369cda
Author: mlamouri <mlamouri@chromium.org>
Date: Fri Sep 30 14:58:23 2016

Web Audio: when media playback requires a user gesture, apply rule to cross origin iframes.

This is an intervention: do not allow cross origin iframes to use Web Audio
without a user gesture. In practice that means that the AudioContext will start
rendering only if it was "unlocked".

Intent to Intervene: https://groups.google.com/a/chromium.org/d/msg/blink-dev/51WbTwn0M_Y/VZuwn8-VAAAJ

This is applying the changes discussed at TPAC and summarised here: https://github.com/WebAudio/web-audio-api/issues/836

BUG= 614115 

Review-Url: https://codereview.chromium.org/2314903002
Cr-Commit-Position: refs/heads/master@{#422112}

[add] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/LayoutTests/http/tests/webaudio/autoplay-crossorigin.html
[add] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/LayoutTests/http/tests/webaudio/resources/autoplay-crossorigin-iframe.html
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/Source/modules/webaudio/AudioBufferSourceNode.cpp
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/Source/modules/webaudio/AudioContext.cpp
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/Source/modules/webaudio/AudioScheduledSourceNode.cpp
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.cpp
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.h
[modify] https://crrev.com/b121dd8b9380574db8d6ebee851c1dfd61369cda/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/86a60cb0983a8bd9689d5c0ce7684f04799ada02

commit 86a60cb0983a8bd9689d5c0ce7684f04799ada02
Author: mlamouri <mlamouri@chromium.org>
Date: Tue Oct 18 15:27:55 2016

Web Audio: record autoplay status when an AudioContext is destroyed.

This is recording if an AudioContext with autoplay restrictions was
block, allowed to play and also record whether allowing start() to
activate the AudioContext would have allowed playback.

BUG= 614115 
TEST=BaseAudioContextTest.cpp (unit tests)

Review-Url: https://codereview.chromium.org/2404743002
Cr-Commit-Position: refs/heads/master@{#425966}

[modify] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/third_party/WebKit/Source/modules/BUILD.gn
[modify] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/third_party/WebKit/Source/modules/webaudio/AudioBufferSourceNode.cpp
[modify] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/third_party/WebKit/Source/modules/webaudio/AudioScheduledSourceNode.cpp
[modify] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.cpp
[modify] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.h
[add] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/third_party/WebKit/Source/modules/webaudio/BaseAudioContextTest.cpp
[modify] https://crrev.com/86a60cb0983a8bd9689d5c0ce7684f04799ada02/tools/metrics/histograms/histograms.xml