Filling a DocumentFragment in the main document can have side effects

[noamr]

"Set and filter HTML" (https://wicg.github.io/sanitizer-api/#set-and-filter-html) creates a DocumentFragment, which is the result of parsing the yet-to-be-sanitized HTML.

This fragment is part of the main document, which means elements that are added to it are created in the context of that document.
This can have side effects for things like image loading - an image loads at the moment it is created rather than at the moment it is connected to an active document.

A remediation for this would be to create that fragment in an inert document.

[mozfreddyb]

Thanks for raising this, @noamr. We totally should prevent image loading and our implementation in Firefox appears to do the right thing already.

[annevk]

It's slightly different. Elements are created in an inert document already as per https://html.spec.whatwg.org/#html-fragment-parsing-algorithm. The question is if removing them and inserting them into a DocumentFragment changes anything.

[noamr]

It's slightly different. Elements are created in an inert document already as per https://html.spec.whatwg.org/#html-fragment-parsing-algorithm. The question is if removing them and inserting them into a DocumentFragment changes anything.

They are also created in an inert document for createContextualFragment (as per spec). Currently all browsers start loading an image immediately - Perhaps this is an observable implementation decision in all browsers to not create that inert document, rather than something to do with this intermediate fragment?

[otherdaniel]

Currently all browsers start loading an image immediately - Perhaps this is an observable implementation decision in all browsers to not create that inert document, rather than something to do with this intermediate fragment?

That's not the intent. We should parse into an inert doc. My current implementation indeed loads stuff prematurely; I'll get that fixed.

There used to be a test case for this exact case, but I think we've dropped it when re-doing the test suite. I'll revive that test, too.

[annevk]

@noamr yeah, I think implementation decisions are leaking.

[mozfreddyb]

The spec text is right. https://html.spec.whatwg.org/#html-fragment-parsing-algorithm is implicitly creating an inert document, by not assigning a BrowsingContext.

We have fixed implementations along the way. Thanks for filing this, Noam!

[annevk]

Do we have a test for this?

I also think we should keep this open because whatwg/html#11669 (comment) might rejigger how this works as it's unclear if we do this for existing methods and if that happens before we add setHTML(), this specification would end up silently regressing.