Bug 212907
| 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 | ||
Adrian Perez
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” :)
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |