In Gecko we use a LoadedScript pointer as the referencing private for dynamic
imports. This is passed through the JS engine as a private value, which doesn't
care what it means. Currently we store this in the module loader as a JS::Value,
but we could just as well unpack it since we know what it is. That lets use a
RefPtr which also keeps it alive and will let use remove some manual reference
counting.
We also don't need to pass it to the CreateDynamicImport method twice.
This change makes it the responsibility of the module loader for keeping the
referencing private alive until FinishDynamicModuleImport is called.
Differential Revision: https://phabricator.services.mozilla.com/D196974
Based on the explanation on the bug, the solution would seem to be to call the
ModuleLoaderBase::OnModuleLoadComplete hook from a microtask. This causes a ton
of test failures.
Instead this patch changes the DOM script loader to implement this hook with a
runnable. This fixes the problem (verified manually) and all tests pass.
(Replacing the runnable with a microtask just in the DOM script loader also
does not work and results in many test failures. I'm still trying to understand
why.)
The changes to ContinueDynamicImport are removed because they are also on this
path and we don't need a microtask as well.
This takes us closer to the state before bug 1842798 landed when all the module
loader used MozPromise internally and completions like this happened via
runnables.
I was not able to immediately come up with a test for this.
Differential Revision: https://phabricator.services.mozilla.com/D185830
According to the spec this should happen as the result of resolving a promise
(see ContinueDynamicImport). If this happens synchronously it's possible for
the importing module to still be in the evaluating state when trying to
instantiate and evaluate the dynamically imported module which breaks the
module loader invariants.
Differential Revision: https://phabricator.services.mozilla.com/D183876
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
According to the spec this should happen as the result of resolving a promise
(see ContinueDynamicImport). If this happens synchronously it's possible for
the importing module to still be in the evaluating state when trying to
instantiate and evaluate the dynamically imported module which breaks the
module loader invariants.
Differential Revision: https://phabricator.services.mozilla.com/D183876
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
According to the spec this should happen as the result of resolving a promise
(see ContinueDynamicImport). If this happens synchronously it's possible for
the importing module to still be in the evaluating state when trying to
instantiate and evaluate the dynamically imported module which breaks the
module loader invariants.
Differential Revision: https://phabricator.services.mozilla.com/D183876
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
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
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
