Closed Bug 1180539 Opened 4 years ago Closed 4 years ago

Correctly dispatch media-playback notifications when an AudioContext is closed/suspended/resumed

Categories

(Core :: Web Audio, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox42 --- fixed

People

(Reporter: ehsan, Assigned: ehsan)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

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.
Assignee: nobody → ehsan
Blocks: 486262
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.
https://hg.mozilla.org/mozilla-central/rev/feb02fb51745
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Depends on: 1209408
Depends on: 1255618
You need to log in before you can comment on or make changes to this bug.