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 original case by adding an extra error reason which is used when
the specifier could be bare and and only warning about relative URLs in this
case.
The same problem happens with import maps enable where "./foo.js" produces an
error about it being a bare specifier, which it's not. For that case make
ParseURLLikeImportSpecifier return a ResolveResult and use the same approach.
Differential Revision: https://phabricator.services.mozilla.com/D151153
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 leaves the code in ScriptLoader and ScriptLoadHandler a lot more readable.
ScriptBytecodeCompressedDataLayout and ScriptBytecodeDataLayout simplify
locating data in the ScriptLoadRequest bytecode buffer when compressing and
decompressing it.
The interface is still error-prone. For example, these classes don't check
that the returned pointers are within the bounds of the buffer.
Differential Revision: https://phabricator.services.mozilla.com/D145011
This leaves the code in ScriptLoader and ScriptLoadHandler a lot more readable.
ScriptBytecodeCompressedDataLayout and ScriptBytecodeDataLayout simplify
locating data in the ScriptLoadRequest bytecode buffer when compressing and
decompressing it.
The interface is still error-prone. For example, these classes don't check
that the returned pointers are within the bounds of the buffer.
Differential Revision: https://phabricator.services.mozilla.com/D145011
This leaves the code in ScriptLoader and ScriptLoadHandler a lot more readable.
ScriptBytecodeCompressedDataLayout and ScriptBytecodeDataLayout simplify
locating data in the ScriptLoadRequest bytecode buffer when compressing and
decompressing it.
The interface is still error-prone. For example, these classes don't check
that the returned pointers are within the bounds of the buffer.
Differential Revision: https://phabricator.services.mozilla.com/D145011
Since mozJSComponentLoader is destroyed after the cycle collector, we need to
break cycles manually before the final cycle collection otherwise we get a
memory leak. Unload() is called at an appropriate earlier point in shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D145567
This adds the parameter to the module loaders evaluation method. I also
rewrote the comments a bit to make this section clearer based on my
understanding of how this works.
Differential Revision: https://phabricator.services.mozilla.com/D145556
The main version of EvaluateModule will continue to use AutoEntryScript, but we
don't always want it's error reporting behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D145492
This allows derived loaders not to support dynamic import if they don't want to.
Module loading for in mozJSComponentLoader will not initially support this.
Differential Revision: https://phabricator.services.mozilla.com/D145491
Module loaders require an event target to use with mozPromise. The default uses
the event loop so doesn't permit implementing a synchronous module loader.
Differential Revision: https://phabricator.services.mozilla.com/D145490
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
Give the caching interfaces default empty implementations so derived classes
don't need to implement them if they don't want any speical behaviour. We don't
use these methods for caching in mozJSComponentLoader.
Differential Revision: https://phabricator.services.mozilla.com/D145488
Olli Pettay
Yoshi Cheng-Hao Huang
Sandor Molnar
Yulia Startsev
Tooru Fujisawa
Jon Coppeard
Matthew Gaudet
Bryan Thrall
Iulian Moraru
Sebastian Hengst
Cristian Tuns
Butkovits Atila
Narcis Beleuzu