[Webkit-unassigned] [Bug 217456] New: WKUserContentController.removeScriptMessageHandler(forName:) seems to be racy

[bugzilla-daemon at webkit.org]

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

            Bug ID: 217456
           Summary: WKUserContentController.removeScriptMessageHandler(for
                    Name:) seems to be racy
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Macintosh
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit API
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: saagar at saagarjha.com

>From what I understand, WKUserContentController.add(_:name:) and WKUserContentController.removeScriptMessageHandler(forName:) both end up calling into WebUserContentControllerProxy::addUserScriptMessageHandler()/WebUserContentControllerProxy::removeUserMessageHandlerForName(), which send a message to the web processes asynchronously about the addition/removal. However, if this is how the API is designed, then there is a race where the UI process and the network process have a different idea of what message handlers are installed. I am seeing an assert being thrown that the reply handler in WebUserContentControllerProxy::didPostMessage() is not called, and it seems like what is happening is that this code gets hit:

RefPtr<WebScriptMessageHandler> handler = m_scriptMessageHandlers.get(messageHandlerID);
if (!handler)
    return;

and we bail out without calling the handler. But the real issue is that we get a message ID we supposedly don't know about, and it seems like what is occurring is that WKUserContentController.removeScriptMessageHandler(forName:) is called to remove a listener, we remove it from our mapping in the UI process, and in between the time the RemoveUserScriptMessageHandler message has been received by the web processes (so it can update its own map) if a message handler gets triggered the web process (which doesn't know about the removal yet) sends the UI process a stale message handler ID.

I'm unsure what the fix for this would be–should the IPC be made synchronous, so this kind of de-sync can't occur? Should we just call the reply handler to swallow the assert?

-- 
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/20201007/92be3c3e/attachment.htm>