I forgot to attach the test case, so here it is.

Deleted: web_audio_test.js 198 bytes

web_audio_test.js 198 bytes View Download

james@

I always get "success" from the repro case. Can you elaborate the problem where "the audio is locked"? What's your expectation here?

M69 does not enforce the autoplay policy against AudioContext. So seeing "success" seems to be WAI.

Sorry, I meant to mark this as Chrome 70. I'm working on an update to howler.js to handle the impending change in Chrome 70 and this issue is making that essentially impossible. If you test it on Canary you don't get any respond from the resume call.

Thank you for providing more feedback. Adding the requester to the cc list.

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

I just tried again with Canary 71.0.3554.0 (MacOS), and I still see "success".
Although it does not hang, this might be a bug. Or the actual enforcement of autoplay policy still might not be in effect.

rtoy@ WDYT?

What if you force it through flags as suggested in the docs?

./Google\ Chrome\ Canary --disable-features=PreloadMediaEngagementData,AutoplayIgnoreWebAudio,MediaEngagementBypassAutoplayPolicies

II just get warnings that the context was not allowed to start. I think it would be natural for resume to reject the promise, but the spec doesn't seem to say that. If it's not allowed to start, the promise is placed on the pending resume list. I didn't see anything that said what these pending resume promises get resolved (or rejected).

See https://webaudio.github.io/web-audio-api/#dom-baseaudiocontext-resume.  The section in running a control message (next paragraph) talks about rejecting these promises, but since the steps were aborted, queuing a control message doesn't happen.

Perhaps a bug in the spec?

Right, there is only a warning in the console, which as far as I can tell means there is no way to programmatically determine that the audio is currently locked. Chrome is about to flip the switch again on this breaking change without providing any sufficient means of handling it.

I'm the author of howler.js, and I've been trying to get this working in the library so that thousand of sites won't break due to this change. The Chrome docs only suggestion is to "simply" call resume from within a click handler, but there is no way to enforce or detect this in a general purpose library.

The expectation was that a promise would function as a promise is intended to function. You would think after the debacle that was the initial auto play release that Google would have put a little more thought into how this gets handled.

Hopefully I'm missing something, but so far neither I or any of our contributors have found a way to handle this in a general use case.

It seems sensible for it to reject the promise, but there might be a reason why we don't.  I'll file an issue on the spec to get this clarified.

Spec issue:  https://github.com/WebAudio/web-audio-api/issues/1759

The linked spec issue is now resolved: when the audio is blocked by autoplay policy, the promise from AudioContext.resume() will neither resolve or reject. Hence, WontFix.

Details can be found in the spec issue above.