Bug 212907 - [GLib] Provide public API to allow customizing the module loader
Summary: [GLib] Provide public API to allow customizing the module loader
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adrian Perez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-08 12:02 PDT by Adrian Perez
Modified: 2020-06-08 12:02 PDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Perez 2020-06-08 12:02:11 PDT
Currently the JS “import” statement in a bare JSCContext—as created by
“jsc_context_new()”—is not usable because the GLib API layer is not
providing the needed callbacks to provide module sources back to JSC.

Today I was having a conversation with Carlos García and this was my
proposal:

   <aperezdc> I think we could have a JSCContext.load-module signal which
      receives a JSCModuleRequest object (or similarly named), which is
      responsible for finding the source code for the module, and then it
      calls webkit_module_request_complete(request, module_source_as_gbytes)
      or webkit_module_request_fail(request, ...)
   <aperezdc> The default implementation could be “always fail for a bare
     JSCContext, and use WebKit's default module loader for a JSCContext
     associated with a WebView”
   <aperezdc> (actually, I am not completely sure that we want to allow
     configuring/overriding how module loading for a web view — maybe we
     just want to support it only for bare JSCContext instances)

This bug is to try and implement something among the lines described
above, and see whether the API feels ”right” :)