If the script is redirected, the redirected URL will be stored in
BaseURL(), therefore we should change to use BaseURL instead.
Differential Revision: https://phabricator.services.mozilla.com/D263371
If the script is redirected, the redirected URL will be stored in
BaseURL(), therefore we should change to use BaseURL instead.
Differential Revision: https://phabricator.services.mozilla.com/D263371
There are shared path between "save bytecode" vs "cache stencil".
This patch just renames everything, and the subsequent bugs and patches will
split the flag and methods.
Differential Revision: https://phabricator.services.mozilla.com/D260911
As a preparation to calculate the "bytecode encoding" separately than "do cache"
for the navigation cache, we should always calculate the flag.
Differential Revision: https://phabricator.services.mozilla.com/D260910
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
This reverts commit 99ce61fb4e.
Revert "Bug 1973206 - Part 5: Remove unused variable in ScriptLoader::MaybePrepareModuleForBytecodeEncodingBeforeExecute. r=nbp"
This reverts commit 73dd64fbdc.
Revert "Bug 1973206 - Part 4: Filter out JSON modules earlier in ScriptLoader::CalculateBytecodeCacheFlag. r=nbp"
This reverts commit 5c8d191154.
Revert "Bug 1973206 - Part 3: Move CalculateBytecodeCacheFlag to instance method as a preparation for the subsequent patches. r=nbp"
This reverts commit 2e9c7ce88a.
Revert "Bug 1973206 - Part 2: Verify the list in IsAlreadyHandledForBytecodeEncodingPreparation. r=nbp"
This reverts commit 64d3a74e4d.
Refactors execution behavior to run asynchronously for inline scripts that are
not generated by the parser.
spec:
https://html.spec.whatwg.org/#prepare-the-script-element
Step 32. If el does not have a src content attribute:
2. type: "module"
...
3. Fetch an inline module script graph, given source text, base URL, settings object, options, and with the following steps given result:
1. Queue an element task on the networking task source given el to perform the following steps:
1. Mark as ready el given result.
Step 33. If ... el's type is "module":
3. Otherwise, if el is not parser-inserted:
3.2.1 Execute the script element scripts[0].
Differential Revision: https://phabricator.services.mozilla.com/D254202
Create InitialStencilAndDelazifications and associate it to ScriptSourceObject,
and store on-demand delazifications into the InitialStencilAndDelazifications.
InitialStencilAndDelazifications is merged into single CompilationStencil when
finishing, but the JS::Stencil-based API is going to be rewritten later not
to merge.
Differential Revision: https://phabricator.services.mozilla.com/D230378
We never reach `CompileFetchedModule` if we have an unknown module type since
we take the module type into account when we do mime type checking, so the file
always fails to load because of MIME mismatch, and we don't get the expected
`TypeError.` Checking if we have an unknown type should happen much earlier in
the process.
Differential Revision: https://phabricator.services.mozilla.com/D222222
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 adds the new parameter to the `NewVisitedSetForTopLevelImport`
method, but we hard-code the module type (which will be addressed in a later
patch)
Differential Revision: https://phabricator.services.mozilla.com/D218555
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 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 adds the new parameter to the `NewVisitedSetForTopLevelImport`
method, but we hard-code the module type (which will be addressed in a later
patch)
Differential Revision: https://phabricator.services.mozilla.com/D218555
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
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
Yoshi Cheng-Hao Huang