This implementes the following requirement from the spec:
https://html.spec.whatwg.org/#fetch-a-single-module-script
12. In both cases, let processResponseConsumeBody given response response and null, failure, or a byte sequence bodyBytes be the following algorithm:
5. Let referrerPolicy be the result of parsing the `Referrer-Policy` header given response.
6. If referrerPolicy is not the empty string, set options's referrer policy to referrerPolicy.
Differential Revision: https://phabricator.services.mozilla.com/D186944
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
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
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
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
The aEarlyHintPreloaderId parameter for StartLoad/StartLoadInternal is changed
to be a member variable of ScriptLoadRequest instead so that an initiator type
of early hints can be set for module requests. Before, ModuleLoader would always
pass in a zero value for the id since ModuleLoaderBase has no concept of early
hints when it calls StartFetch.
As a prerequisite for early hints support, this commit also implements
modulepreload in link headers (Bug 1773056).
Differential Revision: https://phabricator.services.mozilla.com/D180020
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
