Closed Bug 1180539 Opened 5 years ago Closed 5 years ago
Correctly dispatch media-playback notifications when an Audio
Context is closed/suspended/resumed
Since navigating away from a page with an active AudioContext will close it internally, this patch fixes a similar issue to bug 1180535 for Web Audio too.
Attachment #8629726 - Flags: review?(amarchesini) → review+
Hmm, the test is awefully flaky on OSX, but it seems to be fine almost anywhere else. https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1e87c2b327e I'm not sure why yet...
(And of course so far I have not managed to reproduce the test failure...)
I think I figured out the race condition that is causing this test failure. When the playback starts, the state of the AudioContext object stays "suspended" until the media stream graph thread notifies us through a StateChangeTask, but that races against when the next runTest() call tries to call suspend(), so if we do that too soon, suspend() just resolves the promise and returns early. Thankfully there is AudioContext.state, so I think the most robust solution is to poll for that to become "running" before calling parent.runTest(). That seems to fix the test failure.
You need to log in before you can comment on or make changes to this bug.