Per HTML spec:
`document.currentScript` Returns null if the Document is not currently
executing a script or SVG script element (e.g., because the running
script is an event handler, or a timeout), or if the currently executing
script or SVG script element represents a module script.
---
It's ambiguous about whether, for micro tasks, it should return null.
(This section is labelled as "non-normative", as well.)
However, mainstream browsers handle this differently and don't return
null after running microtasks, so we need to clear this and not assume
null persistently, and run the auto-updater for it, regardless if
it's a module or not.
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a
loading principal currently retrieve it from the context node.
Since no current callers require the principal to be the loading
principal, and some already expect it to be the triggering principal
(which there's currently no other way to retrieve), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
Instead, require users to do so. This is a minor translation-unit size
improvement for anyone who never has to use SourceBufferHolder other than
by reference.
This is relevant if scripting is terminated due to execution timeout but there are setTimeout/Interval callbacks pending
or if scripting is disabled altogether.
Microtasks, resolved Promises and Observers are handled after the sync
task that caused them, in the order they were generated.
Also simplifies reentrancy handling.
Based-on: m-c 1193394
This issue is due to the ExecutionContext added in Issue #1691 not handling GetScript()
in a context where script execution is not allowed. This expressed itself in crashes when
playing MP4s with the NoScript extension installed and enabled.
https://bugzilla.mozilla.org/show_bug.cgi?id=1331662
Replace nsJSUtils::EvaluateString calls by ExecutionContext scopes.
ExecutionContext: The mRetValue is not used even though it is checked in various asserts.
This is how it is in the Mozilla code even years later, only the passed in value is used.
ParseTask: JoinDecode() and JoinCompile() run the same code but the type is different
causing a debug assert when it checks the type Script vs ScriptDecode.
(cherry picked from commit 8f577428b7834b7d0f0d5afacbe060fbb1ff2136)
https://bugzilla.mozilla.org/show_bug.cgi?id=1277260
Make PtrInfo into a class and mark it final.
Also fix an erroneous debug assert because mBaseURL not set in one code path.
(cherry picked from commit a1890054011adf0cf87be0d56047418c9f201420)
https://bugzilla.mozilla.org/show_bug.cgi?id=1342012
Support import from timeout handlers by associating the initiating script with the compiled JSScript.
Fix error message that covers all import() failures that don't throw a JS exception.
https://bugzilla.mozilla.org/show_bug.cgi?id=1331662
Partial - Replace nsJSUtils::EvaluateString calls by ExecutionContext scopes.
Left EvaluateString() in nsXBLProtoImplField.cpp until ExecutionContext errors can be fixed.
(cherry picked from commit 22fcfc77971a9bb204df664c474681f4dcf54211)
Support dynamic import from classic scripts by creating ClassicScript objects and associating them with the compiled.
https://bugzilla.mozilla.org/show_bug.cgi?id=1342012
This patch is incomplete, some code in ScriptLoader::EvaluateScript() could not be applied for missing dependencies.
Part 7e will apply the missing dependencies and finish the patch.
(cherry picked from commit ce31a906e801b72f06385b0755710317ccf3658b)
Need PNK_CALL_IMPORT and PNK_IMPORT_META in the node children list or it will abort.
When porting ScriptFetchOptions support, I had 2 constructors, I picked the wrong one.
Missed adding the preference javascript.options.dynamicImport to all.js.
(cherry picked from commit b95ccb711dc41b343d02ae69b3dc4747bbbe86fb)
Apparently Bing does rapid-fire loading/unloading of module scripts that
causes our attempts at resolving and initializing them to end up with
null fetched modules.
Returning null is probably a better way to handle this than crashing
on ms->ModuleRecord() ;-)
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
This commit does several things:
- Moves the pref check from ScriptLoader to ns[I]Document so it can be called on
the document.
- Changes the atrribute freezing function to a better name that takes the
document as a parameter.
- Sets the proper async/defer attributes on HTML script elements based on
keywords and whether they are module scripts or not.
This simplifies handling of combinations of async/defer by assigning one and
only one state to scripts.
If async then always async > if defer or module then defer > otherwise blocking.
This makes sure we don't block body-referred sub-resources by head-referenced
defer and async scripts. This is important for all script loads, not just
modules, but is added here because it was run into while implementing modules.
Moonchild
Basilisk-Dev
Martok
Boris Zbarsky
Brian Smith
Gaming4JC