This removes the global object field from the script load context and gets the
global from the script loader / module loader where necessary.
Differential Revision: https://phabricator.services.mozilla.com/D142833
This gives the module loader a field for the current global, since a module map
is only associated with a single global.
This adds a method to Document to tell the script loader when its global
changes. I'm not sure of when we do this exactly.
Differential Revision: https://phabricator.services.mozilla.com/D142831
The script loader will need to deal with requests from more than one module
loader so this adds methods to the request which dispatch to the correct
loader.
Differential Revision: https://phabricator.services.mozilla.com/D142828
StartModuleLoadImpl moves to the base class and uses to new virtual methods
CanStartLoad and StartFetch which are implemented by the derived class.
Differential Revision: https://phabricator.services.mozilla.com/D141736
Now we can move the JS engine integration hooks into the generic module loader.
There is still some code there to deal with web extension globals. This will be
removed in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D141735
This adds a new virtual to the module loader base, along the same lines as the
one to create a load request for a static import. This makes the
HostImportModuleDynamically hook generic.
Differential Revision: https://phabricator.services.mozilla.com/D141734
This adds a virtual method to nsIGlobalObject and implements it for
nsGlobalWindowInner and SandboxPrivate. This means we don't have to put the
logic for dealing with all the different kinds of globals in once place.
Differential Revision: https://phabricator.services.mozilla.com/D141733
This is used when we explicitly don't want to load cached bytecode. It is
better served by a separate flag in the request than a state.
Differential Revision: https://phabricator.services.mozilla.com/D142042
This also renames 'loading' enum values to 'fetching' since this is more
specific. Loading covers the whole process of loading, which includes the other
states.
Enum values have the leading 'e' removed in line with the coding style for enum
classes.
Differential Revision: https://phabricator.services.mozilla.com/D142041
This removes the microtask checkpoint when instantiating modules and moves the
one when creating a module script to the the script loader.
Differential Revision: https://phabricator.services.mozilla.com/D141252
After enabling bytecode cache for module script, we need to handle
the SRI mismatch on bytecode cache, that requires reloading the script source
again.
Differential Revision: https://phabricator.services.mozilla.com/D140551
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
To add conditional JS::StartIncrementalEncoding, and also to add a bytecode
decoding branch, replace nsJSUtils::CompileModule with raw JSAPI calls with
Stencil.
Differential Revision: https://phabricator.services.mozilla.com/D140291
As a preparation to add bytecode case to CompileOrFinishModuleScript, removed
the shared nsresult variable and make each branch directly return, and also
do early return for error case.
Differential Revision: https://phabricator.services.mozilla.com/D140290
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
After enabling bytecode cache for module script, we need to handle
the SRI mismatch on bytecode cache, that requires reloading the script source
again.
Differential Revision: https://phabricator.services.mozilla.com/D140551
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
To add conditional JS::StartIncrementalEncoding, and also to add a bytecode
decoding branch, replace nsJSUtils::CompileModule with raw JSAPI calls with
Stencil.
Differential Revision: https://phabricator.services.mozilla.com/D140291
As a preparation to add bytecode case to CompileOrFinishModuleScript, removed
the shared nsresult variable and make each branch directly return, and also
do early return for error case.
Differential Revision: https://phabricator.services.mozilla.com/D140290
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
