Closed Bug 1491475 Opened 2 years ago Closed 2 years ago

postpone starting AudioContext until calling AudioContext.resume() or AudioScheduledSourceNode.start()

Categories

(Core :: Audio/Video: Playback, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: alwu, Assigned: alwu)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

We've finished the implementation in bug1489278, but we still hide this feature behind the pref "media.autoplay.block-webaudio".

Since we want to keep the data which we collect in Bug1490074 precise, and it would be affected if doorhanger shows. 

Therefore, we would delay to turn on this pref until we get enough data.
Priority: -- → P3
From telemetry data [1], there are at least 25% audio context which starts producing sound 12+ seconds after sites create them. 

If we enable doorhanger for webaudio before handling this issue, the user would see lots of annoying prompt. 
I think we should not enable it until the spec has a better modification about when we should show the prompt [2].

[1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-10-02&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F64&measure=WEB_AUDIO_BECOMES_AUDIBLE_TIME&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-09-14&table=0&trim=1&use_submission_date=0

[2] https://github.com/WebAudio/web-audio-api/issues/1759#issuecomment-425417175
I've tested all websites which are listed in [1], and here are websites which would be broke when we enable blocking autoplay for web audio.

http://frequency-explorer.timpulver.de/
https://musiclab.chromeexperiments.com/Sound-Waves/
https://musiclab.chromeexperiments.com/Harmonics/
http://microscope.timpulver.de/
http://sequ.timpulver.de/
http://fugue-step.timpulver.de/

In addition, for this one, if you click 'allow' button fast enough, then it could work.
https://musiclab.chromeexperiments.com/Rhythm/

I'm not sure why they would be broke, but it seems to me that these websites didn't handle the case of AudioContext not starting immediately.

[1]
https://bugs.chromium.org/p/chromium/issues/detail?id=835767
https://bugs.chromium.org/p/chromium/issues/detail?id=840866
Hi, Paul,
Could you give me any suggestion about my preliminary patch?
This patch is about to start `AudioContext` when calling `AudioContext.resume()` or `AudioScheduledSourceNode.start()`, otherwise, AudioContext will keep in `suspend` state after it was created.
Thank you!
Attachment #9024893 - Flags: feedback?(padenot)
Comment on attachment 9024893 [details] [diff] [review]
start AudioContext when calling AudioContext.resume() or AudioScheduledSourceNode.start()

I think this would work, but it needs tests.
Attachment #9024893 - Flags: feedback?(padenot) → feedback+
Summary: Enable doorhanger for web audio → postpone starting AudioConext until calling AudioContext.resume() or AudioScheduledSourceNode.start()
Summary: postpone starting AudioConext until calling AudioContext.resume() or AudioScheduledSourceNode.start() → postpone starting AudioContext until calling AudioContext.resume() or AudioScheduledSourceNode.start()
If AudioContext is not allowed to start, we would postpone its state transition from `suspended` to `running`
until site explicitly calls AudioContext.resume() or AudioScheduledSourceNode.start().
Priority: P3 → P2
Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3d997ec4174d
part1 : postpone starting AudioContext until calling AudioContext.resume() or AudioScheduledSourceNode.start(). r=padenot
https://hg.mozilla.org/integration/autoland/rev/3b5ff99abb5e
part2 : modify tests. r=padenot
https://hg.mozilla.org/integration/autoland/rev/345d44957fee
part3 : add test to ensure doorhanger would not dismiss when inaudible media starts. r=cpearce
You need to log in before you can comment on or make changes to this bug.