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.
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
Currently, for untrusted inline scripts, ScriptElement's
MaybeProcessScript() will always:
1) Run GetTrustedTypesCompliantInlineScriptText() in a script runner.
2) Call MaybeProcessScript(nsAString&) with the retrieved source.
3) Return false to indicate parser should not be blocked.
In various cases (no CSP enforcement, web extension, UA widget, etc),
step 1 won't actually run the default policy and the raw string will
be used instead. Consequently, we can just do the same processing as
for trusted script i.e. immediately call and return the result of
MaybeProcessScript(nsAString&), lazily retrieving the source text.
Note that step 3 is incorrect in cases when a script runner is still
needed, but this will be handled in bug 1997818.
Differential Revision: https://phabricator.services.mozilla.com/D273776
This is a follow-up of bug 1947732, covering the remaining Trusted Types checks:
- Document.write/writeln
- WorkerGlobalScope.importScripts
- eval and new Functions
- script enforcement
- pre-navigation check
Differential Revision: https://phabricator.services.mozilla.com/D263688
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
This patch changes the invalid script tag warning to actually include the
invalid tag, which makes it easier to understand what is going wrong.
WebGL pages use invalid types on script elements to store strings. These three
specific strings are used in hundreds of places in our WebGL tests, so don't
warn for them. The first two can be found in WebGL tutorials, so this seems like
an actual convention. "text/something-not-javascript" looks like it is only
used in the WebGL conformance tests, but it is clearly deliberately invalid
so skip warning for it, too, in the interests of reducing warning spam.
I didn't use NS_WARNING_ASSERTION here because that includes the entire
expression that failed, and that is large and not very useful.
Differential Revision: https://phabricator.services.mozilla.com/D212799
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
Modifies the preparation of script tags in order to better follow the
specification. Now, scripts are only considered to have already started
if they have a valid type when being prepared, and only changes to the
src attribute trigger script preparation, instead of for all attributes.
This allows script tags to be re-run after their type and src are
modified, if they haven't run already.
Differential Revision: https://phabricator.services.mozilla.com/D175795
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
agoloman