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 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
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
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
Similar to the ConvertToUTF16 overload for JS owned strings, add an overload for
the UTF8 case. This simplifies later work to switch parsing to UTF8.
Differential Revision: https://phabricator.services.mozilla.com/D164930
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
Classes with virtual methods should have a virtual destructor so deleting an
object through a base class pointer works correctly. I think I got lint
warnings about this when I added a new derived loader.
Differential Revision: https://phabricator.services.mozilla.com/D145489
This removes the global object field from the script load context and gets the
global from the script loader / module loader where necessary.
Differential Revision: https://phabricator.services.mozilla.com/D142833
This gives the module loader a field for the current global, since a module map
is only associated with a single global.
This adds a method to Document to tell the script loader when its global
changes. I'm not sure of when we do this exactly.
Differential Revision: https://phabricator.services.mozilla.com/D142831
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
