Fix WKWebview AudioContext "zombie" state in visibility change#2888
Fix WKWebview AudioContext "zombie" state in visibility change#2888GuoLei1990 wants to merge 3 commits intogalacean:dev/2.0from
Conversation
WalkthroughA bug fix for AudioManager that adds a call to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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
❌ Your patch check has failed because the patch coverage (0.00%) is below the target coverage (60.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## dev/2.0 #2888 +/- ##
===========================================
+ Coverage 83.03% 83.21% +0.17%
===========================================
Files 796 796
Lines 90449 90454 +5
Branches 9503 9497 -6
===========================================
+ Hits 75107 75271 +164
+ Misses 15260 15101 -159
Partials 82 82
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…dling in LingGuang App
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix
What is the current behavior? (You can also link to an open issue here)
On iOS WKWebView, when the app switches to background and returns to foreground, AudioContext may be in a "zombie" state — state reports "suspended", but calling resume() alone won't restart audio rendering.
What is the new behavior (if this is a feature change)?
When visibilitychange event detects audio needs to be resumed, call suspend() first to force reset the AudioContext internal state, then trigger resume() via user gesture to ensure audio recovers correctly.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No
Other information:
This is a known WebKit bug where AudioContext may enter a state where state appears normal but currentTime stops incrementing after returning from background. Calling suspend() first forces a clean internal state reset, which is a common workaround adopted by other audio libraries (PlayCanvas, Tone.js, etc.).
Related: https://bugs.webkit.org/show_bug.cgi?id=263627
Summary by CodeRabbit