(In reply to Henri from comment #5)

This breaks audio on http://titanix.net:8080/ and probably other WebSDR
receivers

In new autoplay policy, we would require developer to create AudioContext after document gets activated by user gesture. If you create AudioContext before that, it would not be allowed to start. You would need to explicit call AudioContext.resume() or AudioScheduledSourceNode.start() after document gets activated in order to start AudioContext.

(In reply to Alastor Wu [:alwu] from comment #6)

(In reply to Henri from comment #5)

This breaks audio on http://titanix.net:8080/ and probably other WebSDR
receivers

In new autoplay policy, we would require developer to create AudioContext after document gets activated by user gesture. If you create AudioContext before that, it would not be allowed to start. You would need to explicit call AudioContext.resume() or AudioScheduledSourceNode.start() after document gets activated in order to start AudioContext.

I'm just a user of that page, so cannot do anything about it. There is not any kind of prompt to allow the audio playback, at least giving that to user would be nice.

(In reply to Henri from comment #7)

I'm just a user of that page, so cannot do anything about it. There is not
any kind of prompt to allow the audio playback, at least giving that to user
would be nice.

Because the result of the shield study we've launched (bug1475099) showed that the doorhanger seemed not really helpful for user, and some people were confused about that, we've decided to remove the doorhanger.

We know that it would increase the possibility to break sites which uses web audio, so we're trying to add other mechanisms which would resume AudioContext from blocking (eg. bug1513733, bug1517324) in order not to break too many sites.