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
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 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
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
I was over eager in introducing the strong pointers to WorkerLoadContext. It turns out that
previously when we were cycle collecting our ScriptLoadRequests, we were also cleaning up everything
related to WorkerLoadContext. Also, in an attempt to fix the cancellation for workers, We
accidentally stopped cleaning up the reference to the cache creator. This patch does the following:
1) cleans up the cache creator reference whenever we finish with a cache load handler. This is done
by calling Fail appropriately. This solves both bug 1798667 (we no longer reach NEW_URI if we fail)
and 1781295 (we no longer leak memory because things were not cleaned up properly).
2) Does no remove the back reference to WorkerLoadContext from the LoadRequest. It turns out that
this is sometimes necessary. There is a chance that we will accidently try to access the
WorkerLoadContext after cancellation. This actually causes problems later on in the module code.
Differential Revision: https://phabricator.services.mozilla.com/D161288
As WorkerLoadContexts now inherit from a non-CC'd loadContextBase, we have two outcomes.
1) we need to break cycles with ScriptLoadRequests manually, so that ScriptLoadRequests can be collected (ScriptLoadRequests must be CC'd).
2) we can now have refptrs to WorkerLoadContexts in the CacheLoadHandler and NetworkLoadHandler classes, and remove any remaining raw pointers to ScriptLoadRequest/WorkerLoadContext. There are cases where the NetworkLoadHandler or CacheLoadHandler might outlive the Worker Loader, so having refpointers here should help us recover in those cases.
Differential Revision: https://phabricator.services.mozilla.com/D160334
This is the most substantial change in the transition from ScriptLoadInfo to ScriptLoadRequest with
regards to data representation. ScriptLoadRequests can have their data incrementally loaded,
so it is already fully decoded and ready to go by the time that we create the source buffer for
worker scripts. This simplifies some of the code, and we can add incremental loading when we are ready.
Differential Revision: https://phabricator.services.mozilla.com/D146180
Here we split ScriptLoadInfo's representation -- we are distinguishing between "what is being loaded"
and "how it is being loaded in a worker context". Requesting review from asuth for the workers side
of things, and jonco for js/loader.
Differential Revision: https://phabricator.services.mozilla.com/D146175
I didn't realize that this would only be used in the DOM script loader, so this is now optional. In
a later stage we might move this over to the ScriptLoadContext as it looks like this might need to
propogate through the module script tree.
Differential Revision: https://phabricator.services.mozilla.com/D146172
This fixes the overly general context kind checks pointed out in the bug and
adds error checking in ImportESModule.
This also showed that JS::ClearModuleEnvironment could fail if the module's
environment had not been initialized yet.
This patch also adds a couple more tests.
Differential Revision: https://phabricator.services.mozilla.com/D151006
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 is used when we explicitly don't want to load cached bytecode. It is
better served by a separate flag in the request than a state.
Differential Revision: https://phabricator.services.mozilla.com/D142042
This also renames 'loading' enum values to 'fetching' since this is more
specific. Loading covers the whole process of loading, which includes the other
states.
Enum values have the leading 'e' removed in line with the coding style for enum
classes.
Differential Revision: https://phabricator.services.mozilla.com/D142041
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
The crashes were occurring due to the missing webext global on dynamically imported modules from a referencing script. There is likely a more elegant way to reintroduce this, but for now this is a quick fix.
Differential Revision: https://phabricator.services.mozilla.com/D139511
