Refactor SubScriptLoader target behavior and other options
Categories
(Core :: XPConnect, enhancement)
Tracking
()
People
(Reporter: arai, Unassigned)
References
(Blocks 1 open bug)
Details
The mozIJSSubScriptLoader.loadSubScript receives an optional obj parameter, that is the target object where the subscript is loaded into.
interface mozIJSSubScriptLoader : nsISupports
{
...
[implicit_jscontext]
jsval loadSubScript(in AString url, [optional] in jsval obj);
This has multiple behaviors depending on the following:
- Where the calling context is : window, system module, frame script, ...
- frame script has special behavior (see bug 1938860)
- What the type of the target object is : global object, some random object, ...
- just load into given global (window, sandbox), or
- run script with extra bindings, and/or
- import global variables into given object
- Whether the target object comes from the current realm/compartment
- load into current global, or
- load into other global such as debuggee
We should have clear distinction between the combinations of the above, with clearer semantics how the target object is used for, when to use which, etc.
For example, if the target object is used for providing extra bindings, the API should be named like *WithBindings, in the same way as the Debugger API's executeInGlobalWithBindings (compared to executeInGlobal for no-extra-binding case)
If the API is used only for importing symbols into the current global, it could be replaced with ES modules for example (e.g. bug 490147).
Also, loadSubScriptWithOptions is used only in testing code (and also some privileged extensions), and that can be removed,
possibly with replacing with new APIs, or existing APIs such as ChromeUtils.compileScript, for async option.
interface mozIJSSubScriptLoader : nsISupports
{
...
[implicit_jscontext]
jsval loadSubScriptWithOptions(in AString url, in jsval options);
Description
•