[wpe-webkit] Synchronous JS interactions with native code

Michael Catanzaro mcatanzaro at igalia.com
Tue Jun 25 07:15:45 PDT 2019

On Mon, Jun 24, 2019 at 7:20 PM, Ryan Walklin <ryan at testtoast.com> 
> So far they have implemented functions that themselves return 
> promises, however I need to implement APIs to directly return 
> function results and variables, e.g. browser.runtime.getManifest() 
> that returns the WebExtension's manifest.json file. I've tried to 
> modify Midori's JS function to use async/await to return the value 
> once the promise resolves, but have had no success so far.

Hm, if you do IPC to the UI process, then the web process will hang for 
an arbitrary amount of time. That's a poor user experience so you 
should avoid that if at all possible. That's surely why Midori is using 
promises everywhere.

As an alternative to promises, you could store the manifest data in the 
web process to ensure no IPC is needed and a result can be returned 
immediately. E.g. when creating your, er, WebKitWebExtension -- this 
terminology clash is very unfortunate -- when creating your 
WebKitWebExtension you can use a 
WebKitWebExtensionInitializeWithUserDataFunction in the web process 
rather than a normal WebKitWebExtensionInitializeFunction, and use 
webkit_web_context_set_web_extensions_initialization_user_data() in the 
UI process. Then you can pass the manifest from the UI process to the 
web process using the GVariant parameter (use it as a dictionary).

Then in window_object_cleared() you can use the JSC API to define some 
function that returns the manifest. You could copy e.g. [1][2] from 
Epiphany, except of course return your manifest data instead of using 
gettext, that example is just to show how to define a C function that 
returns a string that will be accessible to JavaScript. That way you 
can get your manifest into JS without needed to do IPC whenever 
browser.runtime.getManifest() is called.

Good luck!


More information about the webkit-wpe mailing list