When a Chrome update breaks… your microphone volume display

Chrome 66 which is currently rolling out as the stable version introduces changes in the autoplay behaviour of video elements. Which breaks quite a number of WebRTC services.

These autoplay policy changes has been in the works for quite a while. I first heard about them last November that this might affect WebRTC when Dag-Inge Aas tweeted a question:

There is some documentation about this on the Google Developer pages but nothing indicating anything related to WebRTC. I have since run into a some weird bugs related to this but today saw something which seems to have a bit more impact.

Starting with Chrome 66, the AudioContext object, which is part of the WebAudio API, can only be used after the user interacted with the page. Chrome will show an error in the console if the AudioContext is constructed without user interaction:

The AudioContext was not allowed to start. It must be resume (or created) after a user gesture on the page. https://goo.gl/7K7WLu

which points to the documentation above. This is probably a good idea to prevent sites from using WebAudio to play annoying sounds. Unfortunately this also breaks a quite common usage pattern for WebRTC apps where an AudioContext is used to show the microphone volume in a “haircheck” page. Philip Roberts wrote a utility library called “hark” for that a couple of years back. which does this nicely.

After seeing this break on one of the webrtc sample pages (thanks bencc) I investigated a bit more, filed an issue and found this to be pretty widespread, affecting sites like talky.io, Tokbox’s opentokrtc demo, jitsi meet, the mediasoup demo page and even Google Meet:

Here, the AudioContext is used to animate the three green dots in the lower right corner of the (black) video element depending on the microphone input. As the console warning indicates, it is possible to call resume() on the audio context after the user clicked a button.

To make this bug worse, this seems to behave differently on a fresh Chrome profile than on than one which has already played videos with audio on the same origin due to the Media Engagement Index which is explained in the documentation. When testing if this affects your site you might want to check both with an existing profile (which simulates a returning user) as well as a freshly created profile. And mind you that opening the JS console seems to count as interaction just the same as a button click.

Requiring a button click when the user already has given permission to use the microphone which implies a considerable amount of trust for a site seems like overkill. While that is quite possible in terms of user experience this was not required before and it should not be. Even Safari recently tweaked their autoplay policy to allow this use-case.

Displaying microphone volume like this is common enough that it is very surprising this made it to the stable version. If this change is intentional the Chrome/WebRTC release notes have been omitting any indication for three releases in a row. Bugs can happen. Good release notes indicating changes between versions can be incredibly helpful in the attempt to figure out what goes wrong. Without this, hunting down bugs becomes a game of blind man’s buff and I am too old for that.

Stay tuned for updates by starring the Chrome bug!