Please replace webapitestiframe.html with the attached one.
I forgot "context.suspend()" in there that was part of my testing.

Deleted: webapitestiframe.html 1.2 KB

webapitestiframe.html 1.2 KB View Download

This was discussed in b/74483530. It's been broken, and broken for awhile. cc tim since this is blink related.

I personally consider the bug and thus fix is in blink.

Actually, this is the *opposite* issue to b/74483530: in that bug, the issue is that when setMediaPlaybackRequiresUserGesture(true) is set, silent video still autoplays (because of the changes to chrome's default policy about silent video). This is the opposite: non-silent video is *not* playing, even though the user gesture requirement has been turned off, which I think is a more serious issue (because it may prevent an app from working correctly) and according to the reporter this regressed in 67.

Tried just pushing the file into /sdcard on the device and loading it as a file:// url, and loading it into a webview with the same settings as your demo app. Works just fine in m67 stable.

This leads me to think that this is probably blink's fancy tracking where it allows some sites to play media and disallows on other sites, depending on how frequently user as interacted with that site? https://www.blog.google/products/chrome/improving-autoplay-chrome/

It's not clear to me that's enabled in m67 though.

That policy makes no sense on webview, where app developer should have total control over the behavior.

I don't think that code actually exists in webview? I think the only thing that the chrome policy change actually did to webview was allow muted autoplay on all sites regardless of this setting, and otherwise shouldn't have changed anything..

I can't think of anything else that can explain the different behavior observed though.

boliu@chromium.org - it also works fine when the iframe is on the same domain. 
It stops working only when the iframe is on a different subdomain. 

Oh I missed the iframe part of this. file urls are different origin by default, so can simulate cross origin by loading from files as well. And yes. Looks like this used to work in 66, and not anymore at least in trunk, so something definitely changed.

The policy is defined here, and webview only uses the first two:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/media/autoplay_policy.h?rcl=9e18d3e153e9abf830445dc7922413d0c3e2218a&l=24

However, there is a kUserGestureRequiredForCrossOrigin policy that seems to be the net effect here, for no good reason..

Regressed between 3396.46 and .47.

Looking at the CLs that got merged, this one seems to be the only relevant one:
https://chromium-review.googlesource.com/c/chromium/src/+/1054433

Despite what the CL description says, it definitely changes behavior on android as well.

That method has changed again on trunk:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webaudio/base_audio_context.cc?rcl=ea90e377568cce415d261ecd472ab941ccc42a8e&l=686

According to trunk behavior, webview should just disable kAutoplayIgnoreWebAudio:
https://cs.chromium.org/chromium/src/media/base/media_switches.cc?rcl=ea90e377568cce415d261ecd472ab941ccc42a8e&l=332

and this should start working again..?

Yes that should be the case.

I think in the future when experimenting with these policies, should be cognizant of the fact that chrome is not the only embedder out there.

CL: https://chromium-review.googlesource.com/c/chromium/src/+/1093889

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

commit b045799f0ce6520d4edf59349277e2022985d0bd
Author: Bo Liu <boliu@chromium.org>
Date: Fri Jun 08 23:55:54 2018

aw: Disable kAutoplayIgnoreWebAudio

That features allows audio to have a separate auto play policy that
that's independent from the auto play policy of the page. Webview
does not want that behavior and for everything to respect the single
autoplay policy.

Bug:  850445 
Change-Id: I2928a0e077f1ef65cd3ffaea9f643d4f4aab2502
Reviewed-on: https://chromium-review.googlesource.com/1093889
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565783}
[modify] https://crrev.com/b045799f0ce6520d4edf59349277e2022985d0bd/android_webview/lib/aw_main_delegate.cc

I don't think this fix is doing what we want. When landing the AutoplayIgnoreWebAudio feature, we reverted M66 behaviour to M65. Basically, the test case is most likely broken in M65 and was only working for a very short time in M66.

The reason why we had to introduce this flag is because we broke many websites using Web Audio and those websites are now going to be broken with Web Audio.

Unless I'm missing something here, we should probably revert this CL.

> Basically, the test case is most likely broken in M65 and was only working for a very short time in M66.

That's not the case. It works in M65. Maybe something else changed? Is there any particular CL or something worth checking?

Mounir, correct me if I'm misinterpreting this:

I think what Mounir means is that the behaviour in M65 was that some web audio use cases are busted when user gestures *are* required, and that your CL has reintroduced this issue in WebView - not that the behaviour when user gestures aren't required is wrong.

If that's correct then this is indeed the wrong fix :|

What exactly was broken in m65 exactly then?

Certain web audio API use cases never get to play any audio even if there's a user gesture, because the originally rolled out policy change wasn't compatible with a number of existing API usage patterns (especially ones used by games and other things that dynamically generate audio instead of just embedding an <audio> tag).

So old policy had issues, and new policy had bugs, on webview and according to #15 on chrome as well? Until the bugs are worked out, including webview ones, going back to old policy doesn't sound so bad to me.

This is all without understanding what the old policy or new policy actually is. Probably should have mounir or becca take over this, because if that's the wrong fix, then I have no idea what the right fix is.

Yes, probably. Mounir, what we expect to work for WebView, since this has maybe gotten confusing, is for setMediaPlaybackRequiresUserGesture(false) to remove *all* the restrictions on what can autoplay, and just let literally anything (no user gesture, cross-origin iframe, whatever) play anything it likes.

When it's set to true, we're *probably* okay with whatever the current chrome policy is, though it may still be better long term if we come up with a way to allow the app to say "no really, no autoplay without a user gesture at all, even muted/etc" in regards to the feature request from b/74483530 - but that's a separate problem.

boilu@,
Could we get manual verification steps?  

Steps in #1 requires local wamp server, which test team don't have it, so can't repro & verify. I even looked at b/74483530 too.

I've hosted all the needed files on out cloud.
I am attaching the same Android project with the updated URL.

The new URL is: http://chromebug.helloeko.com/webapitest.html
if you want to test it in more environments.

Deleted: WebviewTestCloud.zip 132 KB

WebviewTestCloud.zip 132 KB Download

I tried the URL provided http://chromebug.helloeko.com/webapitest.html on 
Pixel XL / PPR vs webview: 69.0.3457.4 and 66.0.3359.158 
Asus Zenfone 2 / LRX21V and with webview: 69.0.3457.4 and default webview: M39 
and still I can't hear the sound. 
But I can hear the sound while playing on Desktop Chrome browser. 

re #24: Which webview app did you use for testing? You need an app that calls setMediaPlaybackRequiresUserGesture(false). Try the attached shell.

Also mounir: any more input here on the discussion in 16-21?

Deleted: SystemWebViewShell.apk 700 KB

SystemWebViewShell.apk 700 KB Download

`setMediaPlaybackRequiresUserGesture()` changes the autoplay policy of Chrome as much for media elements than Web Audio.

Changing kAutoplayIgnoreWebAudio specifically for WebView is really the wrong approach as you will break all the websites that we initially broke when we released the autoplay policy for Web Audio.

Oh, actually scratch that. The issue is that when we disabled the autoplay policy for Web Audio, we forced the autoplay policy to be back to the default one which means that we ignore all override of the policy, see:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webaudio/audio_context.cc?rcl=8166182690591c6b41921f64bcecbb0d6567cfde&l=315

I think the right fix would be to only force set the policy when it is initially kDocumentUserActivationRequired.

Can you describe this history of changes here, and what problems it's intended to solve. Eg you say this will break websites, but in what case exactly?

I don't know about torne, but at least I'm missing a lot of the history/context here to understand what's happening.

> I think the right fix would be to only force set the policy when it is initially kDocumentUserActivationRequired.

Webview never uses kDocumentUserActivationRequired. Currently it's either kNoUserGestureRequired or kUserGestureRequired. The case that's broken for this particular bug is that kNoUserGestureRequired still requires user gesture for audio in a cross origin iframe.

Is kDocumentUserActivationRequired the default policy in chrome?

> Can you describe this history of changes here, and what problems it's intended 
> to solve. Eg you say this will break websites, but in what case exactly?

Honestly, it would be too long to summarise but in short, the feature you "disabled" for WebView was added to unbreak temporarily websites that were broken with the default autoplay policy. It disables the policy for Web Audio.

> Is kDocumentUserActivationRequired the default policy in chrome?

Yes :)

kDocumentUserActivationRequired is the "default policy" that broke a bunch of websites in chrome? Webview has never used kDocumentUserActivationRequired, so at least that argument never applied to webview? So then... where does that leave things?

I do not remember WebView requiring user gesture required policy. Are you sure it's not using the default policy?

Pretty sure: https://cs.chromium.org/chromium/src/android_webview/browser/aw_settings.cc?rcl=c32a3d1ec4331f10e0efbd5d979a833f8e1a57ce&l=399

hasn't changed in a year

I think we should change that. Though, this is fairly orthogonal to the problem and the fix should be the same.

Changing that brings us back to the problem from b/74483530 though - the app can only express a boolean for whether to require user gestures or not, and if we introduce different behaviour then some apps will consider the resulting behaviour to be broken, so we're going to have to consider the effects carefully.

Right. So where does that leave this bug? Sounds like CL in #14 should be ok in the current state of things? I was intending on merging it to m68.

It fixes the problem with WebView but doesn't fixes the general bug. I will send a CL shortly that fixes the real issue and should fix WebView at the same time.

Issue still repro in webview: M67.0.3396.90, M68.0.3440.27 but is fixed on: M69.0.3461.0

re #25 that's boliu for providing updated webview shell apk 

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

commit dcbf40286ae80c77310cecfb6a390132aad3d5d8
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Fri Jun 15 19:09:18 2018

Autoplay: only disable Web Audio autoplay policy when the document user activation policy applies.

This is affecting WebView that has a different autoplay policy but
also would affect any client using a different policy from the default
one.

Bug:  850445 
Change-Id: Ifaac3e15c4644c32e540b20e62bb3ee70d9a0b12
Reviewed-on: https://chromium-review.googlesource.com/1102827
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567753}
[modify] https://crrev.com/dcbf40286ae80c77310cecfb6a390132aad3d5d8/android_webview/lib/aw_main_delegate.cc
[modify] https://crrev.com/dcbf40286ae80c77310cecfb6a390132aad3d5d8/third_party/blink/renderer/modules/webaudio/audio_context.cc

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 2095ed49a936b45a8e8457dc8de8a839cf1589d6
Author: Bo Liu <boliu@chromium.org>
Date: Mon Jun 18 21:40:19 2018

aw: Disable kAutoplayIgnoreWebAudio

That features allows audio to have a separate auto play policy that
that's independent from the auto play policy of the page. Webview
does not want that behavior and for everything to respect the single
autoplay policy.

Bug:  850445 
Change-Id: I2928a0e077f1ef65cd3ffaea9f643d4f4aab2502
Reviewed-on: https://chromium-review.googlesource.com/1093889
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#565783}(cherry picked from commit b045799f0ce6520d4edf59349277e2022985d0bd)
Reviewed-on: https://chromium-review.googlesource.com/1105239
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#423}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/2095ed49a936b45a8e8457dc8de8a839cf1589d6/android_webview/lib/aw_main_delegate.cc

verified on: K3 Note / MRA58K vs 69.0.3464.0
im able to hear the sound 

verified on: pixel opm1.171019.028 vs webview: 68.0.3440.31