[Webkit-unassigned] [Bug 182528] New: [GTK] WebProcess deadlock loading a web view via a signal from another

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 5 22:34:18 PST 2018


            Bug ID: 182528
           Summary: [GTK] WebProcess deadlock loading a web view via a
                    signal from another
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: Gtk
          Severity: Major
          Priority: P3
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mike at vee.net
                CC: bugs-noreply at webkitgtk.org

A WebProcess deadlock occurs when loading content in a WebKitWebView using webkit_web_view_load_html(), when the call chain causing the load is originates from a signal from another WebView and the single shared process model is being used.

Geary uses a WebKitWebView for both displaying email and composing new messages. If the user opens a composer while viewing an existing message, the existing WebView(s) hangs around while the composer's WebView is constructed, causing them to share a WebProcess:

1. First WebKitWebView is constructed, message body is loaded by call to webkit_web_view_load_html()
2. User opens a message composer, a new WebKitWebView is constructed and message template is loaded using webkit_web_view_load_html()
3. Initial WebKitWebView is destroyed after the composer's view replaces it in the main window, and hence they share a WebProcess.

This works fine if (2) is invoked by a GUI control, say by clicking on the Compose button. If however if the user opens a composer by clicking a mailto link in a message currently displayed by the first web view, then at step (2) the WebProcess freezes and never recovers. In this case, step (2) is started by a call chain invoked from a WebView signal (decide-policy, in this case) emitted from the first.

A workaround is to use g_idle_add() to invoke the composer from the signal handler, so that the signal handler returns before webkit_web_view_load_html() is called on the second view. The deadlock also does not occur when using the multi-process model, but that is inappropriate for Geary. I haven't tested if alternate loading methods (from URI, from bytes, etc) also have the same problem or not.

I guess "don't do this" is a reasonable solution to this bug. However since the the call to webkit_web_view_load_html() was for a different WebView instance, and since the loading and rendering is done out of process, I feel like this is a reasonable thing to expect to work.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180206/c263d167/attachment.html>

More information about the webkit-unassigned mailing list