Request for mechanism to determine if children changed steps are called as a result of script or parser

[lukewarlow]

What problem are you trying to solve?

In TrustedTypes we have a need to distinguish between a script's children being changed by an API (e.g. script.appendChild) or changed by the parser.

This is specifically needed as we treat all parsed scripts as trusted by default. However, it's possible for a script to be manipulated before it's finished parsing, and in those cases it shouldn't be trusted.

What solutions exist today?

Both Chromium and WebKit implement a childrenChanged function on their ContainerNode type which I believe translates to the children changed steps concept defined in the DOM algorithm. However, unlike the spec Chromium and WebKit both provide an argument to the function with details, such as the type (what changed and how it changed), and importantly the source of the change (parser vs API).

We can (and do) use this to invalidate scripts in the above described situation.

How would you solve it?

It would be good if the DOM spec matched the reality of at least 2 implementations (unsure about Gecko), and provided details about the change, at the very least for this use case the source of the change.

Anything else?

See w3c/trusted-types#499 (comment) for a long discussion that lead to this issue being raised.

I'm open to any alternative spec mechanisms we can use to spec this behaviour, so if there's a way today or a simpler change we can use let me know.

[annevk]

cc @hsivonen @smaug---- @rniwa @domfarolino @noamr

[lukewarlow]

cc @otherdaniel as he did the Chromium implementation

[domfarolino]

I am interested in two things here.

1. The integrity of the "is changed by API" bit that Chromium maintains. Are we positive that it is accurate in the ways we expect it to be here? I did just a little bit of digging and I found that unconditionally in the ContainerNode::RemoveChildren() path, the ChildrendChangedSource is always kAPI. But this is a very broad method that covers a ton of cases, and I'm wondering if it sometimes covers parser-only cases that get treated as kAPI cases incorrectly. For example, I found that when an HTMLInputElement gets its type updated, possibly as a result of a parser(I think), we go through this flow: HTMLInputElement::ParseAttribute --> HTMLInputElement::UpdateType --> HTMLInputElement::SetInnerEditorValue() --> ReplaceChildrenWithText --> ContainerNode::RemoveChildren. This kind of seems like innocent parser changes can trigger the children changed flow with the kAPI flag set incorrectly. I'll be honest I haven't spent too much time debugging this case to know whether my speculation is right or not, but specifically I'm interested in understanding if all browsers (that implement this extra non-specified bit) match in all scenarios.
2. The point made by @annevk in Update HTML Parser steps for script element to set "script text" w3c/trusted-types#499 (comment) about whether we derive this bit of information based on (a) "invalidation" (I am actually not sure what this means. Is there a common dfn somewhere), or (b) comparing pre-insert and post-insert children contents to detect mid-parsing API intervention ¹.

Footnotes

1. One point I am not clear on is: is it possible for a node's children to be changed during parser as a result of a non-API action? Like, can the parser itself be responsible for under any scenario? ↩