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

Status: RESOLVED FIXED

(Core :: Web Audio, defect)

Description

[(no longer active)]

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.

Comment 1

[(no longer active)]

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

Comment 2

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/44fff46837cc

Comment 3

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/78ca108fd4cb

Comment 4

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/mozilla-inbound/rev/00d8df86e17e

Comment 5

[(no longer active)]

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...

Comment 6

[(no longer active)]

(And of course so far I have not managed to reproduce the test failure...)

Comment 7

[(no longer active)]

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.

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/feb02fb51745

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/feb02fb51745