[Webkit-unassigned] [Bug 201540] New: Race when loading content into the WebView

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Sep 6 02:05:03 PDT 2019


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

            Bug ID: 201540
           Summary: Race when loading content into the WebView
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcrha at redhat.com
                CC: bugs-noreply at webkitgtk.org

Created attachment 378173

  --> https://bugs.webkit.org/attachment.cgi?id=378173&action=review

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.

-- 
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/20190906/b9138103/attachment.html>


More information about the webkit-unassigned mailing list