Also cancel module load requests when cancelling requests generally.
What was happening here was that a previous load was completing and calling
into the wrong module loader, because the loader to use is determined via the
current global, and this was now associated with a different document / script
loader / module loader.
Differential Revision: https://phabricator.services.mozilla.com/D179787
This patch allows us to reject any outstanding requests when terminating a worker. As this is
controlled by the module loader, the approach I took here was to reject the promises and allow the
moduleloader to
shutdown. I am open to alternatives however.
Differential Revision: https://phabricator.services.mozilla.com/D173290
This change addresses the second issue around worker shutdown with infinitely running dynamic
imports: As the event loop is prevented from running when the worker is dying, we do not want to
delegate to the event loop in this case. This case always has a failing promise. Since this is a
failure case related to the worker dying, we stop running code, rather
than waiting for a tick (that never comes) from the event loop.
Differential Revision: https://phabricator.services.mozilla.com/D171684
When running an infinitely-looping dynamic import, it is possible for the module loader to still be
holding on to that module at shutdown. Shutdown on the worker means that we will no longer run the
event loop, which will execute the dynamic import promises necessary to clear the global. The result
is that the global is kept alive. By calling `Shutdown()` we prevent this partially. We additionally
need to address the failure in the module code (next patch).
Differential Revision: https://phabricator.services.mozilla.com/D171683
This is a required change for dynamic import on workers, as the ScriptLoader is not guaranteed to
live long enough. Once the initial script loading is finished, and the script has executed, the
scriptloader is cleared and the strong reference to the workerRef is cleared so that shutdown is
possible. The workerRef is required in order to access the worker private safely. In order to
address this, we move the GetBaseURI method to the module loader itself. In the future, we should
remove the script loader interface all together.
Differential Revision: https://phabricator.services.mozilla.com/D171682
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
Not related to the rest of the bug. This is a simplification so that we set the
supported import assertions once rather than querying the host every time they
are needed.
Differential Revision: https://phabricator.services.mozilla.com/D164914
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
This is more complicated because it needed a change to the public API now we're
not longer returning an array object. The new API is less error prone since
it's no longer possible for the caller to mutate the object returned.
Depends on D163948
Differential Revision: https://phabricator.services.mozilla.com/D163949
I've looked at this for a while and still don't know how this can happen but it
does seem reasonable to add a check here that we haven't already completed the
request.
Depends on D162386
Differential Revision: https://phabricator.services.mozilla.com/D162387
We're getting a bunch of crashes related to initializing AutoJSAPI from a
JSObject pointer that turns out to be null. That overload of Init() gets the
native global from the JSObject and since we already have a native global in
the module loader we can use the overload that takes that instead. This
overload does a null check so we will catch the case where the global is null
(although that should also not happen).
This might just move crashes elsewhere but it's a reasonable tidyup.
Differential Revision: https://phabricator.services.mozilla.com/D162386
It would be nice to assume this but CompileFetchedModule can potentially fail for reasons that
are not JS-related.
Also check for the exception being |undefined| which would cause
ModuleScript::HasParseError to return false. Such an exception should never be
thrown by parsing but check for it just in case.
Add a diagnostic assert to check module script state is as we expect to
hopefully catch related problems sooner.
Differential Revision: https://phabricator.services.mozilla.com/D160788
I don't know whether this is the problem, but if we try and cancel a request
that has already been cancelled it would produce this crash.
Differential Revision: https://phabricator.services.mozilla.com/D159167
This fixes the original case by adding an extra error reason which is used when
the specifier could be bare and and only warning about relative URLs in this
case.
The same problem happens with import maps enable where "./foo.js" produces an
error about it being a bare specifier, which it's not. For that case make
ParseURLLikeImportSpecifier return a ResolveResult and use the same approach.
Differential Revision: https://phabricator.services.mozilla.com/D151153
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
This allows derived loaders not to support dynamic import if they don't want to.
Module loading for in mozJSComponentLoader will not initially support this.
Differential Revision: https://phabricator.services.mozilla.com/D145491
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
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 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 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
