On Arch Linux, running webkit2gtk-5.0 version 2.36.6-1, using the mouse wheel to scroll any page makes WebKitWebProcess go into an infinite loop and the UI freeze completely. This is deterministic and happens in the official MiniBrowser and other webkit2gtk-5.0-based browsers. Moving around the page works just fine (even with smooth scrolling enabled) when using the PageUp/PageDown keys, arrow keys, and when dragging the scroll bar using the mouse buttons. Only using the mouse wheel triggers the infinite loop. strace indicates that the infinite loop is made of calls like this: poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 2, 0) = 1 ([{fd=3, revents=POLLIN}]) write(27, "\1\0\0\0\0\0\0\0", 8) = 8 futex(0x7f8ae4000b70, FUTEX_WAKE_PRIVATE, 1) = 1 write(27, "\1\0\0\0\0\0\0\0", 8) = 8 futex(0x7f8ae4000b70, FUTEX_WAKE_PRIVATE, 1) = 1 And gdb gives the backtrace in the middle of the infinite loop as: #0 0x00007ffff2aef56d in syscall () at /usr/lib/libc.so.6 #1 0x00007ffff3df5e6a in WTF::WorkQueueBase::dispatch(WTF::Function<void ()>&&) () at /usr/lib/libjavascriptcoregtk-5.0.so.0 #2 0x00007ffff71c1fd1 in () at /usr/lib/libwebkit2gtk-5.0.so.0 #3 0x00007ffff5505616 in () at /usr/lib/libwebkit2gtk-5.0.so.0 #4 0x00007ffff54d85ba in () at /usr/lib/libwebkit2gtk-5.0.so.0 #5 0x00007ffff55d4879 in () at /usr/lib/libwebkit2gtk-5.0.so.0 #6 0x00007ffff2c07d34 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0 #7 0x00007ffff2c07e74 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0 #8 0x00007ffff452f268 in () at /usr/lib/libgtk-4.so.1 #9 0x00007ffff4535599 in () at /usr/lib/libgtk-4.so.1 #10 0x00007ffff46c5e7e in () at /usr/lib/libgtk-4.so.1 #11 0x00007ffff486902e in () at /usr/lib/libgtk-4.so.1 #12 0x00007ffff45aa66b in () at /usr/lib/libgtk-4.so.1 #13 0x00007ffff46d229c in () at /usr/lib/libgtk-4.so.1 #14 0x00007ffff479cb68 in () at /usr/lib/libgtk-4.so.1 #15 0x00007ffff47ce475 in () at /usr/lib/libgtk-4.so.1 #16 0x00007ffff2be9fd0 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0 #17 0x00007ffff2c16798 in () at /usr/lib/libgobject-2.0.so.0 #18 0x00007ffff2c0762c in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0 #19 0x00007ffff2c07e74 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0 #20 0x00007ffff48690b8 in () at /usr/lib/libgtk-4.so.1 #21 0x00007ffff4816fde in () at /usr/lib/libgtk-4.so.1 #22 0x00007ffff7ebdc6b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #23 0x00007ffff7f14001 in () at /usr/lib/libglib-2.0.so.0 #24 0x00007ffff7ebb392 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #25 0x00007ffff2d0730e in g_application_run () at /usr/lib/libgio-2.0.so.0 #26 0x0000555555561268 in () #27 0x00007ffff2a122d0 in () at /usr/lib/libc.so.6 #28 0x00007ffff2a1238a in __libc_start_main () at /usr/lib/libc.so.6 #29 0x0000555555561495 in () Any help to further diagnose the issue is welcome. P.S. I have no reason to suspect this bug is related to the distro build of webkit2gtk-5.0 but here is the recipe for it anyhow: https://github.com/archlinux/svntogit-packages/blob/packages/webkit2gtk-5.0/trunk/PKGBUILD
No idea, and that backtrace makes me wonder if this is _not_ GTK4-specific.
To mitigate this problem I wanted to disable scroll events so I added the following to the browser code: g_signal_connect(view, "scroll-event", G_CALLBACK(dummy_true), NULL); Where "view" is the WebKitWebView and "dummy_true" is the following function: gboolean dummy_true (GtkWidget *w, GdkEvent *e, void *d) { return TRUE; } To my surprise, this did not disable scroll events but instead fixed the bug altogether! Could it be that there were two listeners for scroll events, that the buggy infinite loop was caused by them calling each other repeatedly, and that the above disabled one of them, leaving the other solely in charge of scroll events and hence fixing the bug? I out of my depth to diagnose this further and, although I'm happy to take the above as a workaround for the time being, I would also be glad to keep investigating if told exactly how. Thanks again for your time.
(In reply to Gaetan Bisson from comment #2) > To mitigate this problem... Please disregard the above comment. It is unclear whether this change was what actually fixed the bug. It appears there were other changes to my environment which I must rule out first.
Pull request: https://github.com/WebKit/WebKit/pull/8663
Committed 259530@main (dbc31d00f78f): <https://commits.webkit.org/259530@main> Reviewed commits have been landed. Closing PR #8663 and removing active labels.