Remove layout blockers before invoking arbitrary content callbacks #34482
Conversation
…backs. Signed-off-by: Josh Matthews <josh@joshmatthews.net>
There was a problem hiding this comment.
LGTM,
But I'm wondering if we should not file an issue to review this setup in the light of the spec.
It seems we're dealing here with the intricacies of the script element processing model, as highlighted in the example at https://html.spec.whatwg.org/#script-processing-model:children-changed-steps and I don't see this reflected in our implementation(if only through the absence of any links to these concepts).
I think the current approach will lead to continuously moving the remove_script_and_layout_blockers call to fix crashes(see for example step 7.7.1 of dom insert which runs the insertion steps and which could lead to new crashes when implementing the shadow dom), without addressing the underlying issue of spec compliance.
|
Yeah, I think it's worth having a closer look at it. I'll file that. |
|
Closing in favour of #34505. |
When manipulating the DOM tree we always want web content to only see stable states after any mutations are applied. We introduced script/layout blockers in 14b0de3 to catch cases where an unstable DOM could be exposed to web content. These restrictions were too strict, however; the spec mandates that steps like the
children changedshould be invoked synchronously (eg. step 9 of https://dom.spec.whatwg.org/#concept-node-insert), and it's possible to trigger web content from those steps in various ways (see the new test). Since we're careful to invoke such callbacks at times when the DOM is stable, this means that we need to remove the script/layout blockers right before invoking those callbacks, rather than after they have executed../mach build -ddoes not report any errors./mach test-tidydoes not report any errors