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
Remove raw pointer variant of ScriptLoader::{ConvertToUTF16,ConvertToUTF8} to
make it clearer how the buffer is allocated and how it should be freed.
The consumer in ServiceWorkerScriptCache expects the buffer allocated with
malloc, but given js_malloc and malloc are identical in browser, it also
uses JS::FreePolicy.
Differential Revision: https://phabricator.services.mozilla.com/D181204
The crash of https://bugzilla.mozilla.org/show_bug.cgi?id=1835468 can be
reproduced by HTTP redirect in mochitest-plain.
When the script is being processed, sometimes the preloaded request is
still being loaded (for example, the script is being redirected to
another place). So we use the IsModulleFetched() check before calling
RemoveFetchedModule.
Differential Revision: https://phabricator.services.mozilla.com/D182271
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
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Modifies the preparation of script tags in order to better follow the
specification. Now, scripts are only considered to have already started
if they have a valid type when being prepared, and only changes to the
src attribute trigger script preparation, instead of for all attributes.
This allows script tags to be re-run after their type and src are
modified, if they haven't run already.
Differential Revision: https://phabricator.services.mozilla.com/D175795
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
Tests have shown that web pages use base64url encoded integrity
metadata when using SRI, as other browsers are already supporting it.
To align cross-browser behavior, we'll support base64url and base64
in parallel and update the tests from wpt at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D178147
Cancellation happend in ParsingComplete() and Destroy() but was inconsistent in
which kinds of requests were cancelled and which were cancelled and removed.
This makes one method that cancels and removes everything and uses it in both
places.
Differential Revision: https://phabricator.services.mozilla.com/D168231
This just moves the method definitions so that they appear in roughly in the
order they are executed, to make reading and understanding this easier.
Differential Revision: https://phabricator.services.mozilla.com/D166669
This renames the following in an attempt to give consistent names to off-thread
compliation related things:
- AttemptAsyncScriptCompile -> AttemptOffThreadScriptCompile
- NotifyOffThreadScriptLoadCompletedRunnable -> OffThreadJobCompleteRunnable
- OffThreadScriptLoaderCallback -> OffThreadJobCompleteCallback
Differential Revision: https://phabricator.services.mozilla.com/D166668
The main change in this patch is to prevent access to main-thread objects
while off-thread. This is done by using nsMainThreadPtrHandle to wrap main
thread pointers in the runnable. This prevents access to their targets when
off thread and ensure they are only released on the main thread.
This means that mRunnable is now only accessed on the main thread and so it
doesn't need to be atomic and can be a normal RefPtr. We also don't need to
leak a reference to it in AttemptOffThreadScriptCompile.
This also requires that timing data is moved to the runnable.
Cancellation should always have happened by unlink or destruction of
ScriptLoadContext so handling for that is removed.
Differential Revision: https://phabricator.services.mozilla.com/D166667
This just moves the method definitions so that they appear in roughly in the
order they are executed, to make reading and understanding this easier.
Differential Revision: https://phabricator.services.mozilla.com/D166669
This renames the following in an attempt to give consistent names to off-thread
compliation related things:
- AttemptAsyncScriptCompile -> AttemptOffThreadScriptCompile
- NotifyOffThreadScriptLoadCompletedRunnable -> OffThreadJobCompleteRunnable
- OffThreadScriptLoaderCallback -> OffThreadJobCompleteCallback
Differential Revision: https://phabricator.services.mozilla.com/D166668
The main change in this patch is to prevent access to main-thread objects
while off-thread. This is done by using nsMainThreadPtrHandle to wrap main
thread pointers in the runnable. This prevents access to their targets when
off thread and ensure they are only released on the main thread.
This means that mRunnable is now only accessed on the main thread and so it
doesn't need to be atomic and can be a normal RefPtr. We also don't need to
leak a reference to it in AttemptOffThreadScriptCompile.
This also requires that timing data is moved to the runnable.
Cancellation should always have happened by unlink or destruction of
ScriptLoadContext so handling for that is removed.
Differential Revision: https://phabricator.services.mozilla.com/D166667
Note that modules can't be specified in Link preloads with `rel=preload`,
only in `rel=modulepreload`. We currently only support `rel=preload` in
early hints. See Bug 1798319 for updates on module preloads.
Differential Revision: https://phabricator.services.mozilla.com/D161175
Note that modules can't be specified in Link preloads with `rel=preload`,
only in `rel=modulepreload`. We currently only support `rel=preload` in
early hints. See Bug 1798319 for updates on module preloads.
Differential Revision: https://phabricator.services.mozilla.com/D161175
The problem is that synchronous XMLHttpRequest requests can spin the event loop
and cause us to process dynamic module loads (by calling
JS::FinishDynamicModuleImport) when we are already inside JS::ModuleEvaluate.
The module algorithms assume that they are not reentrant.
The patch changes dyammic module load processing to happen in the same way as
async script loads (of both classic scripts and modules), which are blocked
during sync XHR by Document::SuppressEventHandling calling
ScriptLoader::AddExecuteBlocker.
Differential Revision: https://phabricator.services.mozilla.com/D157218
This patch move the ShouldApplyDelazificationStartegy as well as the
ApplyDelazificationStrategy under FillCompileOptionsForRequest.
As not all delazification strategies are capable of handling modules yet (Bug
1760334), and do not apply to cached-stencil, we have to add extra filters to
prevent ShouldApplyDelazificationStrategy to access custom delazification mode.
Differential Revision: https://phabricator.services.mozilla.com/D150118
This patch move the ShouldApplyDelazificationStartegy as well as the
ApplyDelazificationStrategy under FillCompileOptionsForRequest.
As not all delazification strategies are capable of handling modules yet (Bug
1760334), and do not apply to cached-stencil, we have to add extra filters to
prevent ShouldApplyDelazificationStrategy to access custom delazification mode.
Differential Revision: https://phabricator.services.mozilla.com/D150118
This patch adds a new off-thread delazification strategy, which adds a bit of
overhead to queue function with a priority order, which put the largest function
as the first functions to be delazified.
The intent of this new strategy is to limit the usage of main-thread
delazification to the smallest function, in case where the main-thread would win
the delazification race.
Differential Revision: https://phabricator.services.mozilla.com/D149651
