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
This patch does:
- use our common `Create` pattern also here to move some complexity out of the constructor and improve the error handling.
- give each strong worker ref a unique name for better diagnostics.
- add a `TryShutdown` to the life-cycle worker ref, presumably this may help if the worker dies before any DispatchLoadScript(s) has been called.
Differential Revision: https://phabricator.services.mozilla.com/D192936
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
According to the spec,
https://html.spec.whatwg.org/#run-a-worker
14. In both cases, let onComplete given script be the following steps:
1. If script is null or if script's error to rethrow is non-null, then:
1. Queue a global task on the DOM manipulation task source given worker's relevant global object to fire an event named error at worker.
2. Run the environment discarding steps for inside settings.
3. Abort these steps.
Split EvaluateSourceBuffer into JS::Compile and JS_ExecuteScript.
So if we found the script cannot be compiled and it is a top-level script,
we assign a non-JS-Exception error code to it.
If the script cannot be compiled and it's not a top-level script, this
means it's a script which is loaded by importScripts(), according to the
spec, https://html.spec.whatwg.org/#import-scripts-into-worker-global-scope
the exception will be rethrown.
Differential Revision: https://phabricator.services.mozilla.com/D185532
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
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This patch is only remove the inheriting, but keeping Cancel() implmentation.
The Cancel() is needed in some special cases, such as Worker enters Canceling when WorkerScope is not created.
Depends on D176915
Differential Revision: https://phabricator.services.mozilla.com/D173850
In the test file, worker_bug1824498.mjs, it imports two module scripts,
"foo" and "bar", both are invalid specifiers.
The ModuleLoadRequest of "foo" will be canceled, which in turn will:
1. Cancel all imports of the parent ModuleLoadRequest (worker_bug1824498.mjs)
2. Cancel the ModuleLoadRequest of "bar".
After the step 1, WorkerModuleLoader::OnModuleLoadComplete will be
called, and will shutdown the script loader.
The shutdown causes two problems:
1. When step 2 is executed, it will reject the mReady promise in
ModuleLoadRequest, however when the MozPromise is dispatched, its event
target has been shutdown so an assertion failure is triggered.
2. Also when the ScriptLoaderRunnable of "bar" is received, it also
triggers the assertion failure of the valid SyncLoopEventTarget.
To fix the problem, we delay the shutdown until there's no ongoing module
requests.
Differential Revision: https://phabricator.services.mozilla.com/D175476
This prevents loading the debugger script the same way the worker is loaded.
So prevent loading it as ES Module when the worker is using ES Module.
Differential Revision: https://phabricator.services.mozilla.com/D173257
I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
As mentioned in the previous patch, this patch introduces tracking and shutdown of scriptloaders in
the case that we have multiple scriptloaders involved in module loading.
Differential Revision: https://phabricator.services.mozilla.com/D171686
Earlier, we introduced GetBaseURI to the module loader. This allows us to get the BaseURI for a
dynamic import even after the importing script/module's ScriptLoader has been cleaned up. However,
we now need to be able to handle the case where we need to run the dynamic import and load it. In
order to do this, we need to create a scriptloader configured for dynamic import. The most important
difference between this scriptloader and the one that is normally used for script loading in workers
is that we *do not have a syncLoopTarget* to which we return. There are a couple of reasons for
this:
* Dynamic import (and modules in general) relies on the event loop to resolve. If we create a
syncLoop here, we will end up pausing execution, and this breaks the StartModuleLoad algorithm. We
will never complete and the result will be that we are in the wrong state when we return here.
* We do not have perfect knowledge of the future, so we cannot keep the existing script loader alive
in the case that it might be used for loading in the future.
* We cannot migrate the ModuleLoader to not use sync loading without significantly changing other
aspects of how loading scripts on workers works. This becomes particularily evident with error
handling
(https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/dom/workers/WorkerPrivate.cpp#383-444),
and in addition, for reasons I wasn't able to discern, using the CurrentEventTarget results in hard
to identify errors. When there is time to investigate this fully, the ModuleLoader may move away
from using a syncLoop itself.
For now, all main-script loads (whether they are modules or classic scripts) will use the sync loop,
and all dynamic imports will create a new script loader for their needs that is not using the sync
loop. The book keeping for this is in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D171685
