Custom elements created through setting innerHTML have callbacks called as if they were in the main document |
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.75 Safari/537.36 Steps to reproduce the problem: 1. Define a custom element that keeps track of the order of its constructor and `connectedCallback` calls. 2. Assign a string of HTML containing a few of the custom elements to `innerHTML` of some element that is connected to the document. What is the expected behavior? `connectedCallback` of all of the custom elements should all be called in a group at the end of the set to `innerHTML`. What went wrong? Each `connectedCallback` is called after the constructor, as if the elements were not being created for the HTML fragment parsing algorithm. Relevant spec text: https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token https://html.spec.whatwg.org/multipage/custom-elements.html#cereactions https://w3c.github.io/DOM-Parsing/#dfn-innerhtml AFAICT, setting `innerHTML` causes the "create an element for the token" algorithm to set the "will execute script" variable to false, meaning that the connectedCallback reactions enqueued by creating and appending elements in the fragment will be delayed until the set to `innerHTML` is over and the [CEReactions] attribute would cause the associated queue to be popped / flushed. Did this work before? N/A Does this work in other browsers? No Firefox has the same issue. Safari seems correct. Chrome version: 68.0.3440.75 Channel: n/a OS Version: OS X 10.13.6 Flash Version:
,
Aug 3
,
Aug 3
Safari has the opposite problem, it creates and calls `connectedCallback` on elements in the main document as if they were set with `innerHTML`: https://bugs.webkit.org/show_bug.cgi?id=188284
,
Aug 3
Able to reproduce the issue on Mac 10.13.6 using chrome reported version-68.0.3440.75 & latest Canary-70.0.3511.0 . Observed same behavior from M60 builds to latest Canary. As it is non regression issue, marking it as Untriaged to get it addressed from dev team. Thanks..!
,
Aug 3
,
Aug 6
,
Aug 6
To me, the current Chrome and Firefox behavior look to conform to the specification. 1. Author's constructors and connectedCallback are not called and they are not queued while innerHTML parsing. 2. When parsed nodes are append to the document tree, "try to upgrade" steps are invoked. (See 7.7.2.2 of https://dom.spec.whatwg.org/#concept-node-insert) 3. "try to upgrade" enqueues upgrade reactions. https://html.spec.whatwg.org/multipage/custom-elements.html#concept-try-upgrade 4. CEReactions processing for innerHTML invokes reactions for an element. https://html.spec.whatwg.org/multipage/custom-elements.html#invoke-custom-element-reactions 5. Step 1.2.1 invokes "upgrade reaction" 6. "Upgrade" enqueues "connectedCallback" reaction. (Step 5 of https://html.spec.whatwg.org/multipage/custom-elements.html#concept-upgrade-an-element ) 7. Author's constructor is called 8. Back to "invoke custom element reactions" step 1.2.1. |reactions| is not empty. So "connectedCallback" is called. 9. Back to "invoke custom element reactions" step 1.2.1. |reactions| is empty now. Proceed to next "element queue" for another element.
,
Aug 6
Thanks for the correction! I wasn't paying attention to the "synchronous custom elements flag". |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bickne...@google.com
, Aug 21.1 KB
1.1 KB View Download