Since mozJSComponentLoader is destroyed after the cycle collector, we need to
break cycles manually before the final cycle collection otherwise we get a
memory leak. Unload() is called at an appropriate earlier point in shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D145567
This adds the parameter to the module loaders evaluation method. I also
rewrote the comments a bit to make this section clearer based on my
understanding of how this works.
Differential Revision: https://phabricator.services.mozilla.com/D145556
The main version of EvaluateModule will continue to use AutoEntryScript, but we
don't always want it's error reporting behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D145492
Module loaders require an event target to use with mozPromise. The default uses
the event loop so doesn't permit implementing a synchronous module loader.
Differential Revision: https://phabricator.services.mozilla.com/D145490
Classes with virtual methods should have a virtual destructor so deleting an
object through a base class pointer works correctly. I think I got lint
warnings about this when I added a new derived loader.
Differential Revision: https://phabricator.services.mozilla.com/D145489
Give the caching interfaces default empty implementations so derived classes
don't need to implement them if they don't want any speical behaviour. We don't
use these methods for caching in mozJSComponentLoader.
Differential Revision: https://phabricator.services.mozilla.com/D145488
Module imports can be cyclic so it's more correct to refer to them as graphs.
The spec also uses this term.
Depends on D144599
Differential Revision: https://phabricator.services.mozilla.com/D144600
This renames the method to correspond to StartFetch and adds a status argument
so clients can call this rather than
SetModuleFetchFinishedAndResumeWaitingRequests on error.
Depends on D144595
Differential Revision: https://phabricator.services.mozilla.com/D144596
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 splits the interface of ModuleLoaderBase into sections and restricts acess
for internal methods.
Depends on D141248
Differential Revision: https://phabricator.services.mozilla.com/D141249
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
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
