The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
The original patch had caused some assertions so I rewrote it. This now puts
all untracked top-level requests on the new list while they are being compiled
so handles preload requests too.
Differential Revision: https://phabricator.services.mozilla.com/D119386
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
Replace JS pageload proportion probes with absolute time measurements and add new probes to measure GC and main thread parsing impact during page load.
Differential Revision: https://phabricator.services.mozilla.com/D114388
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D107355
