Add runJavaScriptInFrame for WebPageProxy/WebPage.
<rdar://problem/49755738>
Created attachment 367082 [details] Patch
Comment on attachment 367082 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367082&action=review > Source/WebKit/UIProcess/WebPageProxy.cpp:3570 > m_process->send(Messages::WebPage::RunJavaScriptInMainFrameScriptWorld(script, forceUserGesture, worldName, callbackID), m_pageID); It seems there is not much difference of processing in WebProcess between the different runJavaScript messages. We could call runJavaScriptInFrame here and have just one IPC message for all cases.
Comment on attachment 367082 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367082&action=review >> Source/WebKit/UIProcess/WebPageProxy.cpp:3570 >> m_process->send(Messages::WebPage::RunJavaScriptInMainFrameScriptWorld(script, forceUserGesture, worldName, callbackID), m_pageID); > > It seems there is not much difference of processing in WebProcess between the different runJavaScript messages. > We could call runJavaScriptInFrame here and have just one IPC message for all cases. Sounds like a good idea. In fact, I hesitated a bit on that approach in development. The reason for that is whether or not to give main frames a more streamline implementation than subframes. For main frames, we don't need to ask the hash table to get back a WebFrame/WebFrameProxy. WebPage/WebPageProxy stores them directly.
Thanks Youenn for r+ the patch.
Comment on attachment 367082 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367082&action=review >>> Source/WebKit/UIProcess/WebPageProxy.cpp:3570 >>> m_process->send(Messages::WebPage::RunJavaScriptInMainFrameScriptWorld(script, forceUserGesture, worldName, callbackID), m_pageID); >> >> It seems there is not much difference of processing in WebProcess between the different runJavaScript messages. >> We could call runJavaScriptInFrame here and have just one IPC message for all cases. > > Sounds like a good idea. In fact, I hesitated a bit on that approach in development. The reason for that is whether or not to give main frames a more streamline implementation than subframes. For main frames, we don't need to ask the hash table to get back a WebFrame/WebFrameProxy. WebPage/WebPageProxy stores them directly. It turns out that m_mainFrame could be null in the WebPageProxy when runJavaScriptInMainFrame get called, and therefore there is no way to get the frameID in WebPageProxy and pass it to WebPage. I will land the patch as it is then.
Comment on attachment 367082 [details] Patch Clearing flags on attachment: 367082 Committed r244148: <https://trac.webkit.org/changeset/244148>
All reviewed patches have been landed. Closing bug.