Bug 196750

Summary: Add runJavaScriptInFrame for WebPageProxy/WebPage
Product: WebKit Reporter: Jiewen Tan <jiewen_tan>
Component: WebKit Misc.Assignee: Jiewen Tan <jiewen_tan>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, jiewen_tan, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

Description Jiewen Tan 2019-04-09 16:33:58 PDT
Add runJavaScriptInFrame for WebPageProxy/WebPage.
Comment 1 Radar WebKit Bug Importer 2019-04-09 16:34:23 PDT
<rdar://problem/49755738>
Comment 2 Jiewen Tan 2019-04-09 16:52:29 PDT
Created attachment 367082 [details]
Patch
Comment 3 youenn fablet 2019-04-10 09:48:57 PDT
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 4 Jiewen Tan 2019-04-10 12:37:54 PDT
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.
Comment 5 Jiewen Tan 2019-04-10 12:38:09 PDT
Thanks Youenn for r+ the patch.
Comment 6 Jiewen Tan 2019-04-10 13:42:55 PDT
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 7 WebKit Commit Bot 2019-04-10 13:49:29 PDT
Comment on attachment 367082 [details]
Patch

Clearing flags on attachment: 367082

Committed r244148: <https://trac.webkit.org/changeset/244148>
Comment 8 WebKit Commit Bot 2019-04-10 13:49:31 PDT
All reviewed patches have been landed.  Closing bug.