| Summary: | [GLib] Provide public API to allow customizing the module loader | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Perez <aperez> |
| Component: | JavaScriptCore | Assignee: | Adrian Perez <aperez> |
| Status: | ASSIGNED --- | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
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” :)