Bug 211350 – [GTK] WEBKIT_LOAD_FINISHED not reached if WebKitWebView has no parent

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Jan-Michael Brummer]

Created attachment 398313 [details]
Test Application

In Epiphany we do have tests for our EphyWebView implementation. One of those tests is waiting for WEBKIT_LOAD_FINISHED which will
not occure unless the WebKitWebView is added to a window.

Otherwise only WEBKIT_LOAD_STARTED & WEBKIT_LOAD_COMMITTED are emitted.

I'm attaching a simple demonstration application. Verified by Michael Catanzaro.

[Carlos Garcia Campos]

I don't think this is because the webview doesn't have a parent (even though I don't know why the example works when adding the view to a container). I think it has to do with the soup server and the different run loops, but I'm not sure either. When not starting the soup server and loading the document with load_html instead of load_uri the load completes. The weird thing is that our unit tests also run a soup server and don't add the view to a container, so the problem must be something else. 

The reason why the load doesn't complete is because the WebProcess exists, because the connection to the UI process receives a G_IO_HUP, and WebKit exits the process in that case.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #1)
> I don't think this is because the webview doesn't have a parent (even though
> I don't know why the example works when adding the view to a container). I
> think it has to do with the soup server and the different run loops, but I'm
> not sure either.

That seemed like a pretty good guess, but it's wrong. I cleaned up the example by removing the SoupServer (relying on connection to gnome.org instead) and removing the GMainLoop (relying on only gtk_main()/gtk_main_quit() instead). Problem still occurs. It's definitely related to whether the web view has a parent. It does not have to be visible, but it does need to be parented so that it's part of the widget hierarchy, or the load never finishes. I have no clue why.

Will attach a revised test that's just a simpler version of what Jan-Michael uploaded.

> When not starting the soup server and loading the document
> with load_html instead of load_uri the load completes. The weird thing is
> that our unit tests also run a soup server and don't add the view to a
> container, so the problem must be something else. 

We can agree that this is weird. :P

> The reason why the load doesn't complete is because the WebProcess exists,
> because the connection to the UI process receives a G_IO_HUP, and WebKit
> exits the process in that case.

Really weird. Why would that happen...?

[Michael Catanzaro]

Created attachment 417655 [details]
Simplified version of test

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #2)
> > The reason why the load doesn't complete is because the WebProcess exists,
> > because the connection to the UI process receives a G_IO_HUP, and WebKit
> > exits the process in that case.
> 
> Really weird. Why would that happen...?

Occam's razor prevails again: it happens because the UI process closes the connection. This isn't a great backtrace, but that happens here, immediately before the web process receives G_IO_HUP:

1   0x7f543abb3ed5 IPC::Connection::invalidate()
2   0x7f543ac2eac3 WebKit::AuxiliaryProcessProxy::shutDownProcess()
3   0x7f543acb73f0 WebKit::WebProcessProxy::shutDown()
4   0x7f543ac5c356 /home/mcatanzaro/Projects/GNOME/install/lib/libwebkit2gtk-4.0.so.37(+0x1bd4356) [0x7f543ac5c356]
5   0x7f5437cae90d WTF::RunLoop::performWork()
6   0x7f5437cfbe19 /home/mcatanzaro/Projects/GNOME/install/lib/libjavascriptcoregtk-4.0.so.18(+0x13eee19) [0x7f5437cfbe19]
7   0x7f5437cfc6ff /home/mcatanzaro/Projects/GNOME/install/lib/libjavascriptcoregtk-4.0.so.18(+0x13ef6ff) [0x7f5437cfc6ff]
8   0x7f54367bd110 /home/mcatanzaro/Projects/GNOME/install/lib/libglib-2.0.so.0(+0x5c110) [0x7f54367bd110]
9   0x7f54367be033 g_main_context_dispatch
10  0x7f54367be21f /home/mcatanzaro/Projects/GNOME/install/lib/libglib-2.0.so.0(+0x5d21f) [0x7f54367be21f]
11  0x7f54367be677 g_main_loop_run
12  0x7f54389f3754 gtk_main
13  0x401343 ./test() [0x401343]
14  0x7f543659c1e2 __libc_start_main
15  0x40111e ./test() [0x40111e]

So why is it happening? I'm not sure yet. I did find one bug in both tests: we forget to sink the web view's floating ref with g_object_ref_sink() in the case where we don't call gtk_container_add(). When we don't add it to the widget hierarchy, it's our responsibility to sink the ref and manage the widget's lifetime. I was thinking that might cause the widget to get destroyed too soon, but that's not enough to solve this.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #4)
> So why is it happening? I'm not sure yet.

Occam's razor again: it happens because WebPageProxy::close is called... and that happens because the web view is disposed. :P

The problem turned out to be that, after adding my call to g_object_ref_sink(), I forgot to run 'make' and so never actually tested my fix. Minus one hour of my life, oh well.

Closing because this is a refcounting error in the test.