When a child module fails to load, the parent module that requested it is now used as the source location for the error message.
Differential Revision: https://phabricator.services.mozilla.com/D242884
Given that modules become singleton per each global, and they're not always
fetched, network events should be emulated only when the module is confirmed
not to be stored in the module map.
The EmulateNetworkEvents callside should be more tightly coupled with the actual
StartLoadInternal call.
Differential Revision: https://phabricator.services.mozilla.com/D242315
The referrer info is more directly what we want (what triggered this
load).
I could add this information for non-http channels, but I think it's
probably not worth it. This is useful because it's thread-safe, which
allows me to support off-main-thread parsing of stylesheets that contain
SRI metadata.
It also simplifies the API and avoids getting URIs around in non-error
code paths.
Differential Revision: https://phabricator.services.mozilla.com/D238612
If a document is still processing a stylesheet while document.open occurs,
the defer checkpoint might not have been reached. This causes the
ScriptLoader to block load twice, although it will only unblock once.
Related: Bug 1568171
Differential Revision: https://phabricator.services.mozilla.com/D233156
Incremental-encoding API no longer requires exclusive ownership of JS::Stencil,
and the consumers no longer need to duplicate.
Differential Revision: https://phabricator.services.mozilla.com/D230379
Create InitialStencilAndDelazifications and associate it to ScriptSourceObject,
and store on-demand delazifications into the InitialStencilAndDelazifications.
InitialStencilAndDelazifications is merged into single CompilationStencil when
finishing, but the JS::Stencil-based API is going to be rewritten later not
to merge.
Differential Revision: https://phabricator.services.mozilla.com/D230378
I think the constructor assertions don't need to be preserved, since the
locations where JSExecutionContext was constructed are obviously using a real
global on the main thread. I'm less confident in removing the check for
CycleCollectedJSContext::Get()->MicroTaskLevel(), but it should be ok since the
assertion wasn't failing already.
I'm leaving the profiler label "JSExecutionContext" intact for now so there's
no change in recorded profiles, but we should consider a better name for it in
the future.
Differential Revision: https://phabricator.services.mozilla.com/D218457
The remaining Compile(nsAString) could be inlined as well, but it is only used
in nsJSThunk::EvaluateScript and WindowScriptTimeoutHandler::Call. Right now,
I'm just focusing on use by ScriptLoader.
Differential Revision: https://phabricator.services.mozilla.com/D218452
In InstantiateClassicScriptFromMaybeEncodedSource(), I need to use a local
ErrorResult because calling `aRv.NoteJSContextException(aCx)` must be followed
by an immediate return, but that would avoid adding the compile time to
mMainThreadParseTime.
Differential Revision: https://phabricator.services.mozilla.com/D222301
Using ErrorResult should go away by the end of the patch stack for this bug.
I needed to use some failure error code to indicate when
xpc::Scriptability::Allowed() failed so that callers can skip further use of
JSExecutionContext, and also return NS_OK. NS_ERROR_DOM_NOT_ALLOWED_ERR seemed
a reasonable choice, but it is temporary.
ExecScript(aRetValue) is only called by nsJSThunk::EvaluateScript(), which
initializes the JS::Value parameter to JS::Undefined. You can see in the caller
that it will still be JS::Undefined if any errors happen through use of
JSExecutionContext. Therefore, setting the value to JS::Undefined if `mSkip` at
the beginning of ExecScript() isn't needed any more.
We need to leave any exception on the JSContext for AutoJSAPI to handle, or
those exceptions won't propagate properly. For example, tests like
testing/mochitest/tests/Harness_sanity/test_sanityException.html will fail.
Differential Revision: https://phabricator.services.mozilla.com/D218441
