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
Dynamic import is prevented by IsDynamicImportSupported, and now it now throws
TypeError instead of Error, and related wpt passes with it.
Differential Revision: https://phabricator.services.mozilla.com/D202494
A further problem with dynamically inserted import maps was discovered where
sometimes module scripts would never execute. This happens when the script is
still being fetched when the import map is added.
To fix this, cancel all fetching module preloads as well when an import map is
registered and remove them from the module map. In theory this shouldn't be
necessary but I wasn't able to make the tests pass without this step.
For simplicity also remove all module preloads from the scriptloader's list of
preload requests rather than detecting and ignoring them later on.
Differential Revision: https://phabricator.services.mozilla.com/D204202
Currently we record the URI of each fetching modules and any addtional requests
that are blocked waiting on that fetch. This adds the fetching module request
itself.
This is needed by the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D204201
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
A further problem with dynamically inserted import maps was discovered where
sometimes module scripts would never execute. This happens when the script is
still being fetched when the import map is added.
To fix this, cancel all fetching module preloads as well when an import map is
registered and remove them from the module map. In theory this shouldn't be
necessary but I wasn't able to make the tests pass without this step.
For simplicity also remove all module preloads from the scriptloader's list of
preload requests rather than detecting and ignoring them later on.
Differential Revision: https://phabricator.services.mozilla.com/D204202
Currently we record the URI of each fetching modules and any addtional requests
that are blocked waiting on that fetch. This adds the fetching module request
itself.
This is needed by the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D204201
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
A further problem with dynamically inserted import maps was discovered where
sometimes module scripts would never execute. This happens when the script is
still being fetched when the import map is added.
To fix this, cancel all fetching module preloads as well when an import map is
registered and remove them from the module map. In theory this shouldn't be
necessary but I wasn't able to make the tests pass without this step.
For simplicity also remove all module preloads from the scriptloader's list of
preload requests rather than detecting and ignoring them later on.
Differential Revision: https://phabricator.services.mozilla.com/D204202
Currently we record the URI of each fetching modules and any addtional requests
that are blocked waiting on that fetch. This adds the fetching module request
itself.
This is needed by the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D204201
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
On the main thread, single mozJSModuleLoader instance is shared across all
loads in non-shared global, with resetting the internal state after importing
a module graph.
NonSharedGlobalSyncModuleLoaderScope manages the lifetime of each usage.
Import into the same non-shared global can be nested, but import into the
different non-shared gloobal is not allowed while other import for non-shared
global is ongoing.
Differential Revision: https://phabricator.services.mozilla.com/D199456
In non-shared global, the sync load is performed by separate SyncModuleLoader,
with the following algorithm:
1. copy all loaded modules from async module loader, so that they can be
used in the module graph in SyncModuleLoader
2. import a module graph
3. move all modules to async module loader
ModuleLoaderBase::CopyModulesTo is for step 1, and
ModuleLoaderBase::MoveModulesTo is for step 3.
The consumer should assert that there's no fetching modules.
Differential Revision: https://phabricator.services.mozilla.com/D199455
In order to perform sync load in arbitrary global, add
ModuleLoaderBase::mOverriddenBy field, and let
ModuleLoaderBase::GetCurrentModuleLoader return the overridden loader,
so that the module loading can be overridden by SyncModuleLoader.
AutoOverrideModuleLoader manages the lifetime of the override.
Differential Revision: https://phabricator.services.mozilla.com/D199454
On the main thread, single mozJSModuleLoader instance is shared across all
loads in non-shared global, with resetting the internal state after importing
a module graph.
NonSharedGlobalSyncModuleLoaderScope manages the lifetime of each usage.
Import into the same non-shared global can be nested, but import into the
different non-shared gloobal is not allowed while other import for non-shared
global is ongoing.
Differential Revision: https://phabricator.services.mozilla.com/D199456
In non-shared global, the sync load is performed by separate SyncModuleLoader,
with the following algorithm:
1. copy all loaded modules from async module loader, so that they can be
used in the module graph in SyncModuleLoader
2. import a module graph
3. move all modules to async module loader
ModuleLoaderBase::CopyModulesTo is for step 1, and
ModuleLoaderBase::MoveModulesTo is for step 3.
The consumer should assert that there's no fetching modules.
Differential Revision: https://phabricator.services.mozilla.com/D199455
In order to perform sync load in arbitrary global, add
ModuleLoaderBase::mOverriddenBy field, and let
ModuleLoaderBase::GetCurrentModuleLoader return the overridden loader,
so that the module loading can be overridden by SyncModuleLoader.
AutoOverrideModuleLoader manages the lifetime of the override.
Differential Revision: https://phabricator.services.mozilla.com/D199454
