UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36

Steps to reproduce the problem:
The new autoplay restrictions in Chrome 66 require code changes to unmute audio playback in a user gesture. This is unnecessary and serves only to break web compatibility (see issue 840866).

Currently you have to do something like:

function UnmuteAudio()
{
  // either:
  context = new AudioContext();
  // or:
  existingContext.resume();
}

window.addEventListener("click", UnmuteAudio);

This has four major problems:

#1: It unnecessarily breaks a vast amount of existing web content (issue 840866). Instead the browser could simply automatically unmute the AudioContext in the first input event. Then no code changes would be necessary, and existing content would keep working.

#2: the resuming can only be done in an undocumented list of magic events that change over time. Some are non-obvious such as "gamepadconnected", making it easy to accidentally miss cases and end up with content permanently muted depending on the input device in use. See https://discourse.wicg.io/t/usergesture-event/2774

#3: frameworks, libraries and PWA authors must now code buffering systems in case they try to play audio before the first user gesture. Combined with #2, this significantly raises the complexity required to develop reliable audio playback on the web.

#4: it does not protect against abuse in any way. Abusive content will simply listen for all the magic events and start audio in them. Therefore this requirement serves only to break legitimate content.

What is the expected behavior?
Solution:

Automatically unmute the AudioContext after the first user gesture. Provide an event that fires when this is done. This solves everything:

#1: existing web content keeps working
#2: there is no need to track a changing list of undocumented magic events
#3: there is no need to change code to handle the case of playing audio before the first user gesture; everything just works and unmutes automatically. The event that fires when audio is unmuted can be used to opt-in to queuing audio playback until it will be heard, to make sure initial playback isn't cut off.
#4: it is not any easier to abuse audio playback, because pages still can't play audio before the first user gesture.

What went wrong?
Please consider this seriously. In past issues similar suggestions have been glossed over or ignored. This is one of the reasons Chrome 66 ended up breaking a lot of existing content.

At time of writing, the latest plan is to re-introduce the same rules that Chrome 66 introduced but later in the year. This does not solve any of the listed problems so will simply create the same problems again but later on in the year.

Did this work before? Yes Chrome 65

Does this work in other browsers? Yes

Chrome version: 66.0.3359.139  Channel: stable
OS Version: 10.0
Flash Version: