306950 2026-02-04 04:03:25 -0800 [WPE][WebAudio] UI thread freezes when calling `window.alert()` with an instance of `AudioContext` 2026-02-04 05:10:49 -0800 1 1 1 Unclassified WebKit WPE WebKit WebKit Nightly Build All Linux RESOLVED DUPLICATE 302391 P2 Major --- 1 llepage webkit-unassigned bugs-noreply oldest_to_newest 2177905 0 478248 llepage 2026-02-04 04:03:25 -0800 Created attachment 478248 Web page reproducing the issue The issue is systematic and can be reproduced easily with this page: 2177910 1 llepage 2026-02-04 04:17:26 -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. 2177911 2 llepage 2026-02-04 04:17:57 -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. 2177916 3 llepage 2026-02-04 05:10:49 -0800 *** This bug has been marked as a duplicate of bug 302391 *** 478248 2026-02-04 04:03:25 -0800 2026-02-04 04:03:25 -0800 Web page reproducing the issue 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==