Bug 75427 – WebKit deadlocks when GDK threads are initialized

• Component: WebKitGTK
• Status: UNCONFIRMED

[Thierry Reding]

Created attachment 120865 [details]
Test-case that deadlocks by calling "alert()" in body.onload

I have an application that uses WebKit to display a UI and uses VLC to
display videos. libvlc runs in a separate thread and uses callbacks to
control a GDK window where the video is displayed.

To make this work properly, I initialize GDK threads as described in the
GDK documentation (http://developer.gnome.org/gdk/2.24/gdk-Threads.html)
to serialize accesses to the GDK window between the controlling thread
and the VLC thread.

However, after I initialize GDK threads by calling gdk_threads_init(), I
see that certain operations make WebKit deadlock. After some investigation
I've come up with two test-cases. The first triggers this bug by creating
a WebKitWebView and loading HTML that runs an "alert()" from the body's
onload handler. When running this the popup is displayed, but clicking the
"Close" button triggers the deadlock.

I also have a more elaborate test-case which uses an XMLHTTPRequest object
to send synchronous and asynchronous requests. With synchronous requests, I
can always reproduce the issue when they are run directly from an anchor's
handler but not when I wrap them within a "setTimeout()" call. Asynchronous
requests always work without deadlock.

[Thierry Reding]

Created attachment 120866 [details]
Test-case that deadlocks by running synchronous XMLHTTPRequests.

[Alberto Garcia]

I can reproduce this problem, is ChromeClient::runJavaScriptAlert() run from the main GTK+ thread?

Using gdk_threads_add_idle() before emitting script-alert seems to solve the issue.