[Webkit-unassigned] [Bug 200967] New: WebProcess ProcessSwapping problems

[bugzilla-daemon at webkit.org]

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

            Bug ID: 200967
           Summary: WebProcess ProcessSwapping problems
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: enometh at meer.net
                CC: bugs-noreply at webkitgtk.org

Created attachment 376848

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

log indicating the failure path

for the UI process to talk to the correct webprocess I rely on the
page-created signal in the webprocess. On this signal I can inform
the UI process that this webprocess is handling this particular pageid.

However the page-created signal fails to trigger when navigation is to
(or maybe from) a page which is served by the pagecache.

To test this I have a dummy extension which prints an INITIALIZED message
on webkit_web_extension_initialize and a g_messgage on the
page-created-callback. I turn on

WEBKIT_DEBUG=Process,ProcessSwapping,ProcessSuspension


The attachment shows a selection of the messages I from 

1. loading /tmp/1.html which has a single link to trac.webkit.org,
2. and then navigating to the link
3. and then navigating back

step 3 is loads the page from cache.
the new process is created 11867 - BUT ProcessSwap tells process 11830
to handle back navigation to (/tmp/1.html)
but a page-created callback is not signalled for this step.
my UI process thinks that pageID=6 is handled by process 11854 (from step 2)
and directs it to access its document. This fails as there is no document.
and that process crashes.

I hope this description is sufficiently clear, I'd be glad to 
supply more details as directed.

-- 
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/20190821/194d24b0/attachment-0001.html>