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?
<rdar://problem/70075142>