302391 2025-11-12 03:38:02 -0800 REGRESSION(299424@main): [GStreamer][WPE] WebAudio doesn't resume after window.alert() 2026-02-09 04:10:13 -0800 1 1 1 Unclassified WebKit Media WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 plampe webkit-unassigned llepage philn webkit-bug-importer oldest_to_newest 2158201 0 plampe 2025-11-12 03:38:02 -0800 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 2177917 1 llepage 2026-02-04 05:10:49 -0800 *** Bug 306950 has been marked as a duplicate of this bug. *** 2177918 2 478249 llepage 2026-02-04 05:12:13 -0800 Created attachment 478249 Reproduces the bug systematically 2177919 3 llepage 2026-02-04 05:13:31 -0800 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. 2177926 4 llepage 2026-02-04 05:56:10 -0800 Pull request: https://github.com/WebKit/WebKit/pull/57861 2179402 5 ews-feeder 2026-02-09 04:09:17 -0800 Committed 307066@main (13cab9300fd6): <https://commits.webkit.org/307066@main> Reviewed commits have been landed. Closing PR #57861 and removing active labels. 2179403 6 webkit-bug-importer 2026-02-09 04:10:13 -0800 <rdar://problem/169958734> 478249 2026-02-04 05:12:13 -0800 2026-02-04 05:12:13 -0800 Reproduces the bug systematically audiocontext-alert.html text/html 838 llepage PGh0bWw+CjxoZWFkPgogIDxzdHlsZT4KICAgICogewogICAgICBmb250LXNpemU6IDI0cHg7CiAg ICB9CiAgPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KICA8cD48c3BhbiBpZD0iZnJhbWVzIj4wPC9z cGFuPiBmcmFtZXM8L3A+CiAgPHA+PHNwYW4gaWQ9InRpbWUiPjA8L3NwYW4+IHNlY29uZHM8L3A+ CiAgPGRpdj48YnV0dG9uIGlkPSJ0cmlnZ2VyIj5UcmlnZ2VyIEFsZXJ0PC9idXR0b24+PC9kaXY+ CiAgPHNjcmlwdD4KICAgIGNvbnNvbGUubG9nKCJDcmVhdGluZyBBdWRpb0NvbnRleHQuLi4iKTsK ICAgIG5ldyBBdWRpb0NvbnRleHQoKTsKCiAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgidHJp Z2dlciIpLmFkZEV2ZW50TGlzdGVuZXIoImNsaWNrIiwgKCkgPT4KICAgIHsKICAgICAgY29uc29s ZS5sb2coIkNhbGxpbmcgd2luZG93LmFsZXJ0KCkuLi4iKTsKICAgICAgd2luZG93LmFsZXJ0KCJB bGVydCEiKTsKICAgIH0pOwoKICAgIGNvbnN0IGZyYW1lcyA9IGRvY3VtZW50LmdldEVsZW1lbnRC eUlkKCJmcmFtZXMiKTsKICAgIHJlcXVlc3RBbmltYXRpb25GcmFtZShmdW5jdGlvbiBsb29wKCkK ICAgIHsKICAgICAgZnJhbWVzLnRleHRDb250ZW50ID0gcGFyc2VJbnQoZnJhbWVzLnRleHRDb250 ZW50KSArIDE7CiAgICAgIHJlcXVlc3RBbmltYXRpb25GcmFtZShsb29wKTsKICAgIH0pOwoKICAg IGNvbnN0IHRpbWUgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgidGltZSIpOwogICAgc2V0SW50 ZXJ2YWwoKCkgPT4gdGltZS50ZXh0Q29udGVudCA9IHBhcnNlSW50KHRpbWUudGV4dENvbnRlbnQp ICsgMSwgMTAwMCk7CiAgPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPg==