Bug 201540 – [GTK] Race when loading content into the WebView

• Component: WebKitGTK
• Status: NEW

[Milan Crha]

Created attachment 378173 [details]
test-wk2.c

Using webkit-2.26 branch at r249422. I noticed a race condition, which causes having shown in the WebView the previous page, while the URI of the WebView claims a new page. As it's a race it's not that simple to reproduce, proper timing is needed.

The attached test-wk2.c contains on the first line a comment with a command to compile & run it. Running it under valgrind sometimes helps (G_SLICE=always-malloc valgrind --num-callers=30 --leak-check=no --aspace-minaddr=0x100000000 ./test-wk2). To reproduce, just click the Reload button, can be the first at the top. Click it several times. What it is supposed to do is that it eventually flashes a "Loading..." page, then shows the content of the page again. Both pages use a stamp number, to be able to distinguish them. This stamp is shown in the URL of the page as well and they should match. I made it up to 300 to reproduce it, but sometimes even with stamp 62.

From what I understood (I confess it's only an observation, which can be completely wrong), the new URL is passed into a WebKitWebPage, which is deleted (together with the WebKitWebProcess it resides in) a tick of a second after it's URL is changed, causing no page update. Other time the new url of the WebView doesn't make it into the WebProcess at all (or it's rather that the WebPage is freed before the notify::uri signal is delivered to my callback). Thus I guess there is some flaw in WebKitWebProcess reuse.

[Milan Crha]

Created attachment 378174 [details]
test-wk2-extension.c

This helps to debug what is going on on the WebProcess side. The first line contains a comment with a command to build it and to place it into the place where test-wk2.c expects it to be.