refactor(audio): centralize playback intent and context recovery - #3097
refactor(audio): centralize playback intent and context recovery#3097cptbtptpbcptdtptp wants to merge 2 commits into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev/2.0 #3097 +/- ##
===========================================
- Coverage 85.69% 85.50% -0.19%
===========================================
Files 811 811
Lines 94785 94831 +46
Branches 11542 11585 +43
===========================================
- Hits 81223 81084 -139
- Misses 13474 13657 +183
- Partials 88 90 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
Root cause
Web Audio may leave resume pending while the context is not yet allowed to start: https://www.w3.org/TR/webaudio-1.1/#dom-audiocontext-resume
The previous implementation made each AudioSource await one cached resume Promise. A pre-gesture call could therefore remain pending indefinitely, and later gestures reused the same Promise instead of reaching the native AudioContext. Explicit caller suspension, autoplay unlock, and foreground recovery also shared the same resume path, so a source play could erase caller-controlled suspend state. Finally, foreground recovery only counted already-playing sources and ignored pending playback demand.
Resulting state model
Regression coverage
The audio lifecycle suite now covers:
Verification