1787371 - Suspended AudioContext resumes if you navigate to page from back / forward buttons

Status: VERIFIED FIXED

(Core :: Web Audio, defect, P2)

Description

[sidedishf]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

Similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1375562 -

1. Go to https://webaudiodemos.appspot.com/wubwubwub/ and start the playback (not my site but an easy way to reproduce)
2. Open dev console and run audioCtx.suspend()
3. Browse to another page in the same tab (type in the URL bar or click the 'freesfx' link at the bottom)
4. Click the back button.

(You can also repro if you navigate to the page with the suspended audiocontext via the 'go forward' button. E.g., visit another page, then the page with the audiocontext, suspend it, click the back button, then click the forward button.)

Actual results:

The audio resumes. In the dev tools however audioCtx.state is still 'suspended'.

Expected results:

The audio should stay suspended

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Navigation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[sidedishf]

I think Web Audio might fit this better since the linked issue is also web audio? But I may be wrong.

Comment 3

[Paul Adenot (:padenot)]

Karl, can you have a look at this one? I've been able to reproduce.

Comment 4

[Karl Tomlinson (:karlt)]

The changes described in bug 1660806 comment 1 may still be needed.

Comment 5

[Karl Tomlinson (:karlt)]

Attachment: Bug 1787371 don't resume tracks when their realtime AudioContext is suspended r?padenot

The context may be suspended for any of the following reasons:

• the window is suspended,
• suspend() has been called, or
• the context is not allowed to start.

Comment 6

[Karl Tomlinson (:karlt)]

Attachment: Bug 1787371 test AudioContext.suspend() with navigation r?padenot

When running runBfcacheTest tests from a browser, it needs to be configured to
allow popups from the test server.

The popup is not closed from the test because no window proxy is available with
noopener, as required for back/forward cache testing.
wpt run automatically closes the extra window when starting the next test.

Depends on D157251

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d705cb278a9c
don't resume tracks when their realtime AudioContext is suspended r=padenot
https://hg.mozilla.org/integration/autoland/rev/7303b4a432ee
test AudioContext.suspend() with navigation r=padenot

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/35905 for changes under testing/web-platform/tests

Comment 9

[Cristina Cozmuta (:CrissCozmuta)]

Backed out for causing build bustages on AudioContext.cpp. CLOSED TREE
Backout link
Push with failures
Link to failure log
Failure line : builds/worker/checkouts/gecko/dom/media/webaudio/AudioContext.cpp:1095:27: error: logical 'or' of equal expressions [-Werror=logical-op]

Also, please check this Assertion failure
Failure line: Assertion failure: false, at /builds/worker/checkouts/gecko/dom/media/webaudio/AudioContext.cpp:868

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 11

[Karl Tomlinson (:karlt)]

The assertion failure for invalid transition from closed to running showed up in a test with close() called after sync XMLHttpRequest#send().

The resume after the send() runs off an event dispatched after rather than synchronously when its nested event loop unwinds, and so the resume occurs after the close().

This suspend-close-resume sequence would have resumed tracks even without the patch.

A close-suspend-resume sequence is also possible (if the close is before send() or back/forward cache) and would cause the same assertion failure, but the track suspend count would not return to zero with that sequence.

The assertion fails because the patch changed ResumeInternal() to check for state change after ResumeFromChrome(). We can return early when mCloseCalled.

https://treeherder.mozilla.org/jobs?repo=try&revision=aca6004b42c3b2bdf18e7694add3150ee6443bc0

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf576bff1ef8
don't resume tracks when their realtime AudioContext is suspended r=padenot
https://hg.mozilla.org/integration/autoland/rev/57d91c721c4f
test AudioContext.suspend() with navigation r=padenot

Comment 13

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/cf576bff1ef8
https://hg.mozilla.org/mozilla-central/rev/57d91c721c4f

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 15

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I managed to reproduce this issue on a 2022-08-25 Nightly build on Ubuntu 22.04 using the STR and URL from the Description. Verified as fixed on Firefox 106.0b4(build ID: 20220925185751) and Nightly 107.0a1(build ID: 20220925213821) on Ubuntu 22.04, Windows 10, macOS 12.