Summary: | [GTK] Issue performing a navigation action from DOM bindings | ||
---|---|---|---|
Product: | WebKit | Reporter: | Manuel Rego Casasnovas <rego> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | cgarcia, mrobinson, svillar, xan.lopez |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Manuel Rego Casasnovas
2013-06-11 00:43:02 PDT
(In reply to comment #0) > The following code hangs in WebKit2GTK+ (in WK1 it works properly): > > WebKitDOMDocument* document; > WebKitDOMHTMLElement* body; > WebKitDOMElement* iframe; > > body = webkit_dom_document_get_body(document); > > iframe = webkit_dom_document_create_element(document, "iframe", NULL); > webkit_dom_node_append_child(WEBKIT_DOM_NODE(body), WEBKIT_DOM_NODE(iframe), NULL); The following code has the very same problem: WebKitDOMHTMLElement* body = webkit_dom_document_get_body(document); WebKitDOMElement* link = webkit_dom_document_create_element(document, "a", NULL); webkit_dom_html_anchor_element_set_href(WEBKIT_DOM_HTML_ANCHOR_ELEMENT(link), "http://www.igalia.com"); webkit_dom_node_append_child(WEBKIT_DOM_NODE(body), WEBKIT_DOM_NODE(link), NULL); webkit_dom_html_element_click(WEBKIT_DOM_HTML_ELEMENT(link)); So it seems that the problem is not related to <iframe> tags, but it's a general issue when we try to perform any navigation action from the DOM bindings. Checking the UIProcess backtrace it's clear that the problem is due a synchronous D-Bus call which causes that the UIProcess and it doesn't reply to the WebProcess when it's asked about the navigation policy. UIProcess backtrace: #0 0x00007f366a4f91bd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f366b4514ec in g_main_context_poll (n_fds=1, fds=0xbfc9c0, timeout=25000, context=0xbfbf60, priority=<optimized out>) at gmain.c:3995 #2 g_main_context_iterate (context=0xbfbf60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3696 #3 0x00007f366b4519ca in g_main_loop_run (loop=0xbfc510) at gmain.c:3895 #4 0x00007f366b63e1d3 in g_dbus_connection_send_message_with_reply_sync (connection=connection@entry=0xbb4410, message=message@entry=0xbfaad0, flags=flags@entry=G_DBUS_SEND_MESSAGE_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, out_serial=out_serial@entry=0x0, cancellable=cancellable@entry=0x0, error=error@entry=0x7fffe3a14098) at gdbusconnection.c:2240 #5 0x00007f366b63e5e0 in g_dbus_connection_call_sync_internal (connection=0xbb4410, bus_name=bus_name@entry=0xbfc4f0 ":1.0", object_path=0xbf9e80 "/org/webkit/gtk/WebExtensionTest", interface_name=interface_name@entry=0xba6390 "org.webkit.gtk.WebExtensionTest", method_name=method_name@entry=0x407ab8 "GetTitle", parameters=parameters@entry=0x7f3604005a40, reply_type=0x7f366b67010f, flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=-1, fd_list=0x0, out_fd_list=0x0, cancellable=0x0, error=0x0) at gdbusconnection.c:5564 #6 0x00007f366b640895 in g_dbus_connection_call_with_unix_fd_list_sync (connection=<optimized out>, bus_name=bus_name@entry=0xbfc4f0 ":1.0", object_path=<optimized out>, interface_name=interface_name@entry=0xba6390 "org.webkit.gtk.WebExtensionTest", method_name=method_name@entry=0x407ab8 "GetTitle", parameters=parameters@entry=0x7f3604005a40, reply_type=0x7f366b67010f, reply_type@entry=0x0, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, out_fd_list=out_fd_list@entry=0x0, cancellable=cancellable@entry=0x0, error=error@entry=0x0) at gdbusconnection.c:5908 #7 0x00007f366b649d25 in g_dbus_proxy_call_sync_internal (proxy=0xba7250, method_name=<optimized out>, parameters=0x7f3604005a40, flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=<optimized out>, fd_list=fd_list@entry=0x0, out_fd_list=out_fd_list@entry=0x0, cancellable=0x0, error=error@entry=0x0) at gdbusproxy.c:2910 #8 0x00007f366b64bc43 in g_dbus_proxy_call_sync (proxy=<optimized out>, method_name=<optimized out>, parameters=<optimized out>, flags=<optimized out>, timeout_msec=<optimized out>, cancellable=<optimized out>, error=0x0) at gdbusproxy.c:3102 #9 0x000000000040500b in testWebExtensionGetTitle(WebViewTest*, void const*) () #10 0x00007f366b47407d in test_case_run (tc=0xb24390) at gtestutils.c:1714 #11 g_test_run_suite_internal (suite=suite@entry=0xab70c0, path=<optimized out>, path@entry=0x7f366b4ba6ad "") at gtestutils.c:1767 #12 0x00007f366b4741f6 in g_test_run_suite_internal (suite=suite@entry=0xb264c0, path=<optimized out>, path@entry=0x7f366b4ba6ad "") at gtestutils.c:1778 #13 0x00007f366b4741f6 in g_test_run_suite_internal (suite=suite@entry=0xb264a0, path=<optimized out>, path@entry=0x7f366b4ba6ad "") at gtestutils.c:1778 #14 0x00007f366b47455b in g_test_run_suite (suite=0xb264a0) at gtestutils.c:1823 #15 0x0000000000405904 in main () I've checked that this works properly if I use an async D-Bus call, so it's not a WK bug. Anyway I'm wondering if we should add some documentation warning the users about this issue, explaining that if they use a WebKitWebExtension synchronously this kind of deadlock could happen while playing with the DOM bindings. What do you think? (In reply to comment #2) > Checking the UIProcess backtrace it's clear that the problem is due a synchronous D-Bus call which causes that the UIProcess and it doesn't reply to the WebProcess when it's asked about the navigation policy. > > UIProcess backtrace: > > #0 0x00007f366a4f91bd in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x00007f366b4514ec in g_main_context_poll (n_fds=1, fds=0xbfc9c0, timeout=25000, context=0xbfbf60, priority=<optimized out>) at gmain.c:3995 > #2 g_main_context_iterate (context=0xbfbf60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3696 > #3 0x00007f366b4519ca in g_main_loop_run (loop=0xbfc510) at gmain.c:3895 > #4 0x00007f366b63e1d3 in g_dbus_connection_send_message_with_reply_sync (connection=connection@entry=0xbb4410, message=message@entry=0xbfaad0, flags=flags@entry=G_DBUS_SEND_MESSAGE_FLAGS_NONE, > timeout_msec=timeout_msec@entry=-1, out_serial=out_serial@entry=0x0, cancellable=cancellable@entry=0x0, error=error@entry=0x7fffe3a14098) at gdbusconnection.c:2240 > #5 0x00007f366b63e5e0 in g_dbus_connection_call_sync_internal (connection=0xbb4410, bus_name=bus_name@entry=0xbfc4f0 ":1.0", object_path=0xbf9e80 "/org/webkit/gtk/WebExtensionTest", > interface_name=interface_name@entry=0xba6390 "org.webkit.gtk.WebExtensionTest", method_name=method_name@entry=0x407ab8 "GetTitle", parameters=parameters@entry=0x7f3604005a40, reply_type=0x7f366b67010f, > flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=-1, fd_list=0x0, out_fd_list=0x0, cancellable=0x0, error=0x0) at gdbusconnection.c:5564 > #6 0x00007f366b640895 in g_dbus_connection_call_with_unix_fd_list_sync (connection=<optimized out>, bus_name=bus_name@entry=0xbfc4f0 ":1.0", object_path=<optimized out>, > interface_name=interface_name@entry=0xba6390 "org.webkit.gtk.WebExtensionTest", method_name=method_name@entry=0x407ab8 "GetTitle", parameters=parameters@entry=0x7f3604005a40, reply_type=0x7f366b67010f, > reply_type@entry=0x0, flags=flags@entry=G_DBUS_CALL_FLAGS_NONE, timeout_msec=timeout_msec@entry=-1, fd_list=fd_list@entry=0x0, out_fd_list=out_fd_list@entry=0x0, cancellable=cancellable@entry=0x0, > error=error@entry=0x0) at gdbusconnection.c:5908 > #7 0x00007f366b649d25 in g_dbus_proxy_call_sync_internal (proxy=0xba7250, method_name=<optimized out>, parameters=0x7f3604005a40, flags=G_DBUS_CALL_FLAGS_NONE, timeout_msec=<optimized out>, > fd_list=fd_list@entry=0x0, out_fd_list=out_fd_list@entry=0x0, cancellable=0x0, error=error@entry=0x0) at gdbusproxy.c:2910 > #8 0x00007f366b64bc43 in g_dbus_proxy_call_sync (proxy=<optimized out>, method_name=<optimized out>, parameters=<optimized out>, flags=<optimized out>, timeout_msec=<optimized out>, > cancellable=<optimized out>, error=0x0) at gdbusproxy.c:3102 > #9 0x000000000040500b in testWebExtensionGetTitle(WebViewTest*, void const*) () > #10 0x00007f366b47407d in test_case_run (tc=0xb24390) at gtestutils.c:1714 > #11 g_test_run_suite_internal (suite=suite@entry=0xab70c0, path=<optimized out>, path@entry=0x7f366b4ba6ad "") at gtestutils.c:1767 > #12 0x00007f366b4741f6 in g_test_run_suite_internal (suite=suite@entry=0xb264c0, path=<optimized out>, path@entry=0x7f366b4ba6ad "") at gtestutils.c:1778 > #13 0x00007f366b4741f6 in g_test_run_suite_internal (suite=suite@entry=0xb264a0, path=<optimized out>, path@entry=0x7f366b4ba6ad "") at gtestutils.c:1778 > #14 0x00007f366b47455b in g_test_run_suite (suite=0xb264a0) at gtestutils.c:1823 > #15 0x0000000000405904 in main () > > > I've checked that this works properly if I use an async D-Bus call, so it's not a WK bug. > > Anyway I'm wondering if we should add some documentation warning the users about this issue, explaining that if they use a WebKitWebExtension synchronously this kind of deadlock could happen while playing with the DOM bindings. What do you think? I see, yes, so the problem is not the DOM code itself, but that it's called in a D-BUS sync message handler. D-BUS uses a nested main loop for sync messages in the caller, so if the web process tries to send a sync message to the UI process, both will be waiting forever. It's unfortunate because we can't know whether a DOM call can produce a sync communication between web and UI processes, but at least we can control the D-BUS messages that our extension uses. I'm not sure it's necessary to document it, any synchronous call is always discouraged, we use them in the unit tests, but not in production code. I'm going to close this as invalid, since it's not actually a WebKit bug. |