Remove custom element state when is attribute is blocked#396
Conversation
| 1. Set |elementWithLocalAttributes| to | ||
| |configuration|["{{SanitizerConfig/elements}}"][|elementName|]. | ||
| 1. If |child|'s [=is value=] is not `null`: | ||
| 1. Set |isAttribute| to «[ "`name`" → "`is`", "`namespace`" → null ]». |
| 1. If |child|'s [=is value=] is not `null`: | ||
| 1. Set |isAttribute| to «[ "`name`" → "`is`", "`namespace`" → null ]». | ||
| 1. If [=is attribute allowed=] for |isAttribute| given |configuration|, | ||
| |child| is [=/blocked=]: |
There was a problem hiding this comment.
This reads weird. Should it be "given configuration and child"?
There was a problem hiding this comment.
Ah yeah, I copy pasted that from #385 and removed the handleJavascriptNavigationUrls parameter carelessly.
|
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 |
3 participants
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