This reverts commit 524a1fc191.
Revert "Bug 2020707 - Part 5: Gate speculation rules script support behind a pref. r=dom-core-reviewers,jjaschke"
This reverts commit 11741d18ad.
Revert "Bug 2020707 - Part 4: Unregister speculation rules when their script element is removed. r=dom-core-reviewers,hsivonen"
This reverts commit 5202943dc9.
Revert "Bug 2020707 - Part 3: Report an exception if speculation rules parsing fails. r=dom-core-reviewers,jjaschke"
This reverts commit 70c5aa5425.
Revert "Bug 2020707 - Part 2: Add support for speculationrules script type. r=dom-core-reviewers,jjaschke"
This reverts commit 65b30a350b.
Revert "Bug 2020707 - Part 1: Allow speculation rules to be registered to the document from scripts. r=hsivonen,jjaschke"
This reverts commit 28c7050de9.
Revert "Bug 2020704 - Part 2: Add parser for speculation rule sets. r=hsivonen,jjaschke"
This reverts commit eabb8c6eb3.
Revert "Bug 2020704 - Part 1: Add speculation rules crate. r=dom-core-reviewers,jjaschke"
This reverts commit cd65bed005.
Make DOMString a regular nsAutoTString with some special methods for
performance in some hot getters. For that, we need to change a bit
nsTString:
* Support for unowned buffers: Owned buffers now are represented by
STRINGBUFFER|OWNED flags, rather than REFCOUNTED.
* Inlining of the destructor: It showed up in profiles, it's also just
a few instructions, so probably worth it. We could OOL the owned path
I guess, if we wanted to.
* Inlinling and reordering of NonVoidStringToJsval. Old code had
special DOMString path inline with [buffer, literal, copy] paths,
then out of line code with [literal, buffer, copy]. Instead,
consolidate everything in a [buffer, literal, copy] inline path.
Do the same for UTF8/Latin1 strings too for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D288148
When processing a non-trusted inline script, we must run a TrustedTypes
default policy callback on the source text, which in particular may:
- Generally be executed asynchronously in a script runner (thus
requiring to block the parser in the meantime).
- Modify the script type, for example between classic and module (thus
changing the expected blocking behavior for the parser).
Currently, ScriptElement::MaybeProcessScript() returns a boolean
telling callers whether they need to block the parser. Most callers
ignore it but for those that don't, the behavior described above make it
impossible to know the correct desired returned value in advance for
non-trusted inline scripts. Current code always always tell callers not
to block the parser, which is incorrect and causing assertion failures.
This patch adds an optional nsIParser argument to MaybeProcessScript(),
which becomes responsible of blocking the parser when needed. For
external and trusted inline scripts we can continue to try and process
the script immediately and use the result to determine whether to block
the parser. Similarly, for non-trusted inline scripts in context where
it is safe to run script, we can run the default policy callback before
the processing attempt and blocking decision.
For non-trusted inline scripts with a default policy callback that need
to be executed in a script runner, we always block the parser while
waiting that script runner to be executed and only decide to unblock it
after the attempt to process the script.
Differential Revision: https://phabricator.services.mozilla.com/D272372
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
Currently logic is duplicated in HTMLScriptElement and SVGScriptElement's
HasScriptContent() implementations. Rename these methods to only check
hether we have external script content, and move the check for inline
script content directly in ScriptElement::MaybeProcessScript.
Differential Revision: https://phabricator.services.mozilla.com/D253789
Includes only support for dynamically loading style sheets from `<link>`
elements and `Link` header fields.
The remaining support, including preloading, is completed in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D191745
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
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
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
SVG and HTML ScriptElements now use a new base GetScriptType common
method instead of an individual duplicate implementation.
Make a big (unimportant) meta bug to do more of this later?
(avoids code duplication between SVG and HTML, updates old SVG code).
160 WPT subtests newly pass (100% in this test file) 🎉
Differential Revision: https://phabricator.services.mozilla.com/D180200
Same rg + sed shenanigans as the first patch.
There were two that could fail, both due to OOM:
* HTMLInputElement::AfterSetAttr: If we fail (only in the type=range
case) we end up with an old value without it being clamped by
min/max/step.
* HTMLBodyElement::AfterSetAttr: If we fail we won't peek up the
DocShell's frame margins and styling could be incorrect.
That seems better than having to deal with broken states after we've
already set the attribute.
Depends on D176069
Differential Revision: https://phabricator.services.mozilla.com/D176070
This needs to change `nsContentUtils` methods because of used by the method.
Then, we can make some there callers are also `const` methods.
Depends on D162065
Differential Revision: https://phabricator.services.mozilla.com/D162066
agoloman