- Move UpdateReferrerPolicy from ScriptLoadRequest to ModuleLoadRequest,
as this can only happend for a module load.
- Add UpdateReferrerPolicy method to ModuleScript.
Introduces a new UpdateReferrerPolicy method for ModuleScript,
allowing the referrer policy to be updated based on the associated
ModuleLoadRequest.
Differential Revision: https://phabricator.services.mozilla.com/D255127
In mochitest-browser tests, it's possible for the about:neterror page to
load. This triggers aboutNetError.html, which in turn loads aboutNetError.mjs.
Occasionally, the load promise from
LoadRequestedModules(aboutNetError.mjs) is never resolved because the
PromiseJobRunnable is not executed if the global is in the process of
shutting down.
To avoid this issue, we now use the synchronous version of
LoadRequestedModules when loading chrome resources.
Differential Revision: https://phabricator.services.mozilla.com/D257676
We need to check if we have an unsupported attribute before resolving the
specifier because, according to the spec, the unknown attribute should be
reported before the invalid specifier.
Differential Revision: https://phabricator.services.mozilla.com/D221998
Synthetic modules do not have any dependencies, so calling
`GetRequestedModulesCount` results in cash. This patch fixes this by making
`ResolveRequestedModules` return early for synthetic modules.
Differential Revision: https://phabricator.services.mozilla.com/D218561
This patch adds a module type parameter to
`ModuleLoaderBase::{CreateStaticImport,CreateDynamicImport},` and gets rid of a
bunch of hard-coded `JS::ModuleType::JavaScript.` However, the module type is
still hard-coded when we call `CreateDynamicImport` and `CreateStaticImport`.
Differential Revision: https://phabricator.services.mozilla.com/D218556
This patch gets rid of most hard-coded `JS::ModuleType::JavaScript` in
`js/loader/ModuleLoaderBase.cpp`. However, the module type is still hard-coded
when constructing the `ModuleLoadRequest` (will be addressed in a later patch).
Differential Revision: https://phabricator.services.mozilla.com/D218554
This patch is a small step towards the end goal, so we hardcoded the module
type to `JS::ModuleType::JavaScript`, but that will get changed in a later
patch.
Differential Revision: https://phabricator.services.mozilla.com/D218553
The module maps (`mFetchingModules` and `mFetchedModules`) in
`ModuleLoaderBase`, and `VisitedURLSet` were previously only keyed by the URL
and used the `nsURIHashKey` hashtable key class. This is no longer sufficient,
and the key should also contain the module type.
This patch introduces a new hashtable key class called `ModuleMapKey` and
changes `mFetchingModules`, `mFetchedModules`, and `VisitedURLSet` to use the
new key type.
To make this a bit easier to review, this first patch only introduces the new
key type and hard-codes the type to Javascript, where the key is constructed.
The hard-corded module types will be fixed in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D155160
Synthetic modules do not have any dependencies, so calling
`GetRequestedModulesCount` results in cash. This patch fixes this by making
`ResolveRequestedModules` return early for synthetic modules.
Differential Revision: https://phabricator.services.mozilla.com/D218561
This patch adds a module type parameter to
`ModuleLoaderBase::{CreateStaticImport,CreateDynamicImport},` and gets rid of a
bunch of hard-coded `JS::ModuleType::JavaScript.` However, the module type is
still hard-coded when we call `CreateDynamicImport` and `CreateStaticImport`.
Differential Revision: https://phabricator.services.mozilla.com/D218556
This patch gets rid of most hard-coded `JS::ModuleType::JavaScript` in
`js/loader/ModuleLoaderBase.cpp`. However, the module type is still hard-coded
when constructing the `ModuleLoadRequest` (will be addressed in a later patch).
Differential Revision: https://phabricator.services.mozilla.com/D218554
This patch is a small step towards the end goal, so we hardcoded the module
type to `JS::ModuleType::JavaScript`, but that will get changed in a later
patch.
Differential Revision: https://phabricator.services.mozilla.com/D218553
The module maps (`mFetchingModules` and `mFetchedModules`) in
`ModuleLoaderBase`, and `VisitedURLSet` were previously only keyed by the URL
and used the `nsURIHashKey` hashtable key class. This is no longer sufficient,
and the key should also contain the module type.
This patch introduces a new hashtable key class called `ModuleMapKey` and
changes `mFetchingModules`, `mFetchedModules`, and `VisitedURLSet` to use the
new key type.
To make this a bit easier to review, this first patch only introduces the new
key type and hard-codes the type to Javascript, where the key is constructed.
The hard-corded module types will be fixed in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D155160
In StartDynamicImport, if StartModuleLoad failed, the request would be
kept in mDynamicImportRequests until shutdown.
This fixes the problem by removing it from mDynamicImportRequests once
StartModuleLoad fails.
Differential Revision: https://phabricator.services.mozilla.com/D213016
In the following module graph:
0.html
+---- 1.mjs
+---- non_existing.mjs
+---- 3.mjs
+----- 2.mjs
+---- 3.mjs
Both 1.mjs and 2.mjs have a common submodule called 3.mjs
But 1.mjs also has a non-existing submodule, so we can't instantiate the
module graph of 1.mjs. which in turn will cancel 3.mjs
But 3.mjs is also a sub-module of 2.mjs, so in order to instantiate the
module graph of 2.mjs, we skip canceling 3.mjs when we processed 1.mjs
Differential Revision: https://phabricator.services.mozilla.com/D209210
Yoshi Cheng-Hao Huang