Bug 302391

Summary: REGRESSION(299424@main): [GStreamer][WPE] WebAudio doesn't resume after window.alert()
Product: WebKit Reporter: Pawel Lampe <plampe>
Component: MediaAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: llepage, philn, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Reproduces the bug systematically none

Pawel Lampe
Reported 2025-11-12 03:38:02 PST
This is a regression after https://commits.webkit.org/299424@main When window.alert() is used on WPE port along with existing WebAudio pipline, the "resume" step that is executed after actual handling of .alert() (not implemented on WPE) freezes as WebAudio pipeline cannot finish the state transition from READY to PLAYING. The demo that reproduces problem: https://scony.github.io/web-examples/javascript/alert.html?ac=1 - expected: the counters count without any interruption. - actual: the counters freeze after ~5s (when window.alert() is called) I tried locally a partial reverts of https://commits.webkit.org/299424@main: - just removing clocksync helps - just adding queue back does not help
Attachments
Reproduces the bug systematically (838 bytes, text/html)
2026-02-04 05:12 PST, Loïc Le Page
no flags
Loïc Le Page
Comment 1 2026-02-04 05:10:49 PST
*** Bug 306950 has been marked as a duplicate of this bug. ***
Loïc Le Page
Comment 2 2026-02-04 05:12:13 PST
Created attachment 478249 [details] Reproduces the bug systematically
Loïc Le Page
Comment 3 2026-02-04 05:13:31 PST
When calling `window.alert()` with the WPE flavor of WebKit it is just stopping the `AudioContext` and then restarting it. So, the expected result would be to have the different counters (frames and time in seconds) keeping on running. But what we obtain is that the counters are frozen (because the UI thread is frozen) during the time spent in the web page. If you click on "Trigger Alert" at time=3 seconds, it will be frozen during 3 seconds. If you click on "Trigger Alert" at time=20 seconds, it will be frozen during 20 seconds. The issue comes from the fact that when the UI thread is restarting the `AudioContext`, it is waiting synchronously for the underlying GStreamer pipeline to switch to the `Playing` state but this is not happening immediately. The audio buffers managed by the `AudioContext` are timestamped monotonically by a dedicated thread before being pushed to the rendering pipeline. This timestamping is not reset to zero after restarting the pipeline whereas the running time of this pipeline is effectively reset to zero when passing by the `Ready` state. So, when restarting the pipeline the timestamp of the next pushed buffer is the running time of the web page (like 3 seconds or 20 seconds in the former examples), whereas the pipeline is restarting at zero and then the `clocksync` in the pipeline is waiting during all this time preventing the pipeline to pre-roll and change state. The solution is quite easy, we just need to reset the timestamp when restarting the pipeline. It can be done using 2 different approaches: - letting the pipeline do the timestamping itself (by enabling "do-timestamp" in the `appsrc` and setting the pushed buffers PTS to 0) - manually reset the actual timestamping when the `AudioContext` is restarted.
Loïc Le Page
Comment 4 2026-02-04 05:56:10 PST
EWS
Comment 5 2026-02-09 04:09:17 PST
Committed 307066@main (13cab9300fd6): <https://commits.webkit.org/307066@main> Reviewed commits have been landed. Closing PR #57861 and removing active labels.
Radar WebKit Bug Importer
Comment 6 2026-02-09 04:10:13 PST
Note You need to log in before you can comment on or make changes to this bug.