Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lukewarlow opened this issue May 16, 2024 · 2 comments
Labels
addition/proposal New features or enhancements needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan topic: nodes

Comments

@lukewarlow
Copy link
Member

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.

@lukewarlow lukewarlow added needs implementer interest Moving the issue forward requires implementers to express interest addition/proposal New features or enhancements labels May 16, 2024
@annevk
Copy link
Member

annevk commented May 16, 2024

@annevk annevk added topic: nodes needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan and removed needs implementer interest Moving the issue forward requires implementers to express interest labels May 16, 2024
@lukewarlow
Copy link
Member Author

cc @otherdaniel as he did the Chromium implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan topic: nodes
Development

No branches or pull requests

2 participants