[Webkit-unassigned] [Bug 75427] New: WebKit deadlocks when GDK threads are initialized

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=75427

           Summary: WebKit deadlocks when GDK threads are initialized
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: thierry.reding at avionic-design.de


Created an attachment (id=120865)
 --> (https://bugs.webkit.org/attachment.cgi?id=120865&action=review)
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.