[Webkit-unassigned] [Bug 206364] Make the callAsyncJavaScriptFunction function actually be async (so await works)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 17 10:47:05 PST 2020


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

--- Comment #8 from Devin Rousso <drousso at apple.com> ---
Comment on attachment 387938
  --> https://bugs.webkit.org/attachment.cgi?id=387938
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=387938&action=review

>>>> Source/WebCore/bindings/js/ScriptController.cpp:607
>>>> +    functionStringBuilder.append("(async function(");
>>> 
>>> One issue with making a function `async` is that they _always_ return a `Promise`.  I think it would be better to have `ScriptController:callInWorld` take an `enum class IsAsync { Yes, No };` so that callers can decide whether or not they want this.
>> 
>> Which is fine, because literally the only client of this is "callAsyncJavaScriptFunction" which expects promise results.
> 
> Why would the API change here? When the Promise that’s returned is resolved, we IPC the result back to the UI process, so I think it should not be (very) observable to users. (Like if you treat it like a non async function, and do something like “return 42;”, everything Just Works and the UI process is called back with “42”.)
> 
> I think the only concern here is that async functions have slightly different semantics than non async functions. I think(?) things like reserved identifiers and such. But I think that’s ok here, especially because this will be documented.

I misread how `ScriptController::callInWorld` was being used.  My apologies for the confusion.

-- 
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/20200117/f890d872/attachment.htm>


More information about the webkit-unassigned mailing list