Sanitize while parsing

[noamr]

Instead of parsing into a fragment and then statically sanitizing that fragment, sanitize as we parse.
This entails the following changes:

• The sanitizer config is propagated to the parser and kept as a new parser flag ("parser sanitizer configuration").
• The "safe" flavor of sanitization is kept as a boolean flag in the parser ("remove javascript navigation URLs"), as that is a special safety check not kept in the sanitizer configuration.
• The fragment created to hold the result is created in the inert document when sanitizing to avoid creation-time side effects (see Nodes are made non-inert before sanitizing #12560).
• Instead of a recursive "sanitize" algorithm operating on a node tree, we define a "sanitize" algorithm that operates on a single Element, along with two helper checks: "sanitizer config allows comments" and "sanitizer config allows processing instruction target" (other node types do not need to check the sanitizer).
• For "replace with children", we replaced the parser's "root insertion target" flag with an "insertion target redirection map" (mapping a node to an insertion location). This map is used to redirect insertions from the root dummy element to the target DocumentFragment, and also to redirect elements to their nearest non-replaced ancestor when a child is stripped but its children are kept.

Note that this still leaves out important follow ups, where we need to sometimes sanitize before the element is even created (e.g. declarative shadow roots and is), and having a live sanitizer config while parsing gives us the infrastructure for that.

Closes #12560
Closes #12543

• At least two implementers are interested (and none opposed):
  • Chromium
  • WebKit (as per @annevk)
  • Mozilla (as per @mozfreddyb)
• Tests are written and can be reviewed and commented upon at:
  • This mostly keeps existing behavior. The observable difference is coalescing of text nodes while parsing. This was modified in tests in Remove special text node behavior from streaming sanitizer web-platform-tests/wpt#59541.
  • https://wpt.fyi/results/sanitizer-api/sanitizer-inert-document.html checks that images are created as part of an inert document
• Implementation bugs are filed:
  • Chromium: works already
  • Gecko: see https://bugzilla.mozilla.org/show_bug.cgi?id=2043150
  • WebKit: doesn't require its own bug report
• MDN issue is filed: N/A, no behavior change
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/dynamic-markup-insertion.html ( diff )
/parsing.html ( diff )

[noamr]

@mozfreddyb @annevk @evilpie @zcorpan @otherdaniel
PTAL

[otherdaniel]

Generally looks good to me, but I don't think I fully understand the subtleties here.

---

I had expected some sort of sanitizer tie-in somewhere around "create an element for a token" (parsing.html#create-an-element-for-the-token), to close the custom element/is-attribute loopholes. Did I overlook something?

[noamr]

Generally looks good to me, but I don't think I fully understand the subtleties here.

I had expected some sort of sanitizer tie-in somewhere around "create an element for a token" (parsing.html#create-an-element-for-the-token), to close the custom element/is-attribute loopholes. Did I overlook something?

You didn't, that would be a follow up where we apply the sanitizer on a token in particular situations.
I wanted this PR to not change behavior and then iterate on those fixes.

I added a comment to the OP about this.

[evilpie]

I wonder if it would be cleaner to have something like:

1. If configuration["processingInstructions"] exists, then:
   1. Return whether configuration["processingInstructions"] contains piTarget.
2. Otherwise, return whether configuration["removeProcessingInstructions"] does not contain piTarget.

First time reading this the fallthrough from 1.1. tripped to 3. tripped me up.

[noamr]

This wouldn't be according to the spec style, but I reworded it a bit to be more readable perhaps

[evilpie]

Nice, I am not an expert on the parser, but that actually looks like quite an elegant integration. Especially the redirectLocation handling should be reviewed with more experience in this area.

I also really like how much cleaner the the sanitize algorithm looks now.

This does not yet handle the is attribute, right? I would have expected some adjustments in create an element for a token in that case.

[noamr]

Nice, I am not an expert on the parser, but that actually looks like quite an elegant integration. Especially the redirectLocation handling should be reviewed with more experience in this area.

I also really like how much cleaner the the sanitize algorithm looks now.

This does not yet handle the is attribute, right? I would have expected some adjustments in create an element for a token in that case.

Right, I was planning to do that as a follow up.

[noamr]

Closing in favor of #12756 (stacked PR)