Remove custom element state when is attribute is blocked

[evilpie]

This depends on changes in #385 that haven't happened yet.

I am not really certain if there isn't some other data structure that we need to patch for this. Presumably this would be easier to specify when we do streaming parsing.

Fixes #387.

---

Preview | Diff

[otherdaniel]

Looks good editorially, but I wonder whether this would execute the custom element constructor during parsing?

As I understand this, this would create the custom element, and then later remove it again. If so, I'd expect this to execute the custom element's constructor, and thus bypass sanitization in a sense.

[evilpie]

Looks good editorially, but I wonder whether this would execute the custom element constructor during parsing?

As I understand this, this would create the custom element, and then later remove it again. If so, I'd expect this to execute the custom element's constructor, and thus bypass sanitization in a sense.

No it doesn't AFAIK. The custom constructor (if not removed) is only invoked when inserting. IIRC because the custom elements registry is null for those documents we use for parsing?

You can actually try this out with div.setHTML('<div is="custom-div"></div>') in Firefox Nightly.

[evilpie]

Rebased. Should be ready for review, but can't land before #387 of course.

[evilpie]

@otherdaniel I would appreciate your review on this!

[noamr]

Maybe wait with this until after the upstream?

[otherdaniel]

Looks good editorially, but I wonder whether this would execute the custom element constructor during parsing?
As I understand this, this would create the custom element, and then later remove it again. If so, I'd expect this to execute the custom element's constructor, and thus bypass sanitization in a sense.

No it doesn't AFAIK. The custom constructor (if not removed) is only invoked when inserting. IIRC because the custom elements registry is null for those documents we use for parsing?

You can actually try this out with div.setHTML('<div is="custom-div"></div>') in Firefox Nightly.

To be honest, I'm still a little confused here.

• https://wicg.github.io/sanitizer-api/#set-and-filter-html
  • Sanitizer's setAndFilter calls the HTML fragment parsing algorithm with the context element.
• https://html.spec.whatwg.org/#html-fragment-parsing-algorithm
  • The HTML Fragment Parsing Algorithm, step 3, gets the context node's context document.
  • I thought that's the Document that gets passed down to the "create element" operation.
• https://html.spec.whatwg.org/#create-an-element-for-the-token
  • steps 6 + 7 look up a custom element registry for |intendedParent|
  • step 10 calls https://dom.spec.whatwg.org/#concept-create-element, with a registry derived in step 7
• https://dom.spec.whatwg.org/#concept-create-element
  • step 2 looks up a custom element registry for |document| (if the registry from the previous step is "default")
  • steps 4.3 + 4.4 seem to always run an upgrade operation, either directly or as a task.

So... the way I read the specs, I'd still expect your example of div.setHTML('<div is="custom-div"></div>') to throw the custom-div constructor (if it's indeed a registered custom element for the document of that initial div).

As an additional point.. if the HTML fragment parsing algorithm doesn't run the custom element constructor anyhow, then why do we even bother with this whole thing? My understanding is that the sanitizer algorithm sits between the parsing and insertion in the document. If the whole logic only runs when inserting and thus after sanitization, wouldn't this whole point be moot?

---

As said above... I find the whole thing confusing, and am not very confident in my analysis above.

Our implementation seems to slightly deviate from what I find in the specs, in that a custom element registry is expressedly passed in to the parser, and when |scripting mode| is Inert that registry is forced to null. My gut feeling is that this is the better way: If we can guarantee that the parser doesn't execute custom element script during parsing (in this context), then that seems more reliable than fixing this up afterwards.