Closed Bug 1102502 Opened 5 years ago Closed 5 years ago
[Custom Elements] attached
Callback does not seem to be called when a custom element is added using inner HTML
1.36 KB, text/html
Fire custom elements attachedCallback when elements are created and inserted into the document by the parser. v2
6.61 KB, patch
|Details | Diff | Splinter Review|
5.70 KB, patch
|Details | Diff | Splinter Review|
I found this while working on gaia-header tests . It seems that when we insert a custom element using innerHTML, attachedCallback is not called. createdCallback and detachedCallback are correctly called though. Could be related to bug 1087460?  https://github.com/gaia-components/gaia-header NI Guillaume who volunteered to produce a smaller testcase.
The reduced test case is here: http://jsbin.com/xigipipiqi/1/quiet Open the web console. I add then remove a custom element with the following methods: - HTML tag in HTML source - innerHTML - document.createElement - Instantiate the custom element class All these methods properly trigger created/attached/detached callbacks, except the innerHTML that doesn't fire attachedCallback. This callback is executed in Chrome. This seems to confirm there is a bug here.
I think this is a chrome bug. I've filed it here: https://code.google.com/p/chromium/issues/detail?id=435701 Although, this may be behavior that we may want to change in the spec.
I agree that attachedCallback should not be called before createdCallback, but it should be called after createdCallback, don't you think?
Looks like Firefox removes web components from the source when using ctrl-S to save a page...
Attachment #8538400 - Attachment is obsolete: true
Hey William, can we move forward here? It's really painful that the attachedCallback callback is not called when using innerHTML...
This is a spec bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27437 It's related to this clause: "If the created callback exists for an element, all other callbacks must not be enqueued until after this created callback's invocation had started."  There is an inconsistency in the spec regarding whether an attachedCallback should be enqueued. Blink implements it one way and we implement the other way. I think the intent was to make sure that we don't get attributeChanged callbacks for attributes added by the parser, but in this case it's also preventing the attached callback. Here is a patch that changes it to do what Blink does as I think it's closer to the intended behaviour.  http://w3c.github.io/webcomponents/spec/custom/#types-of-callbacks
Attachment #8538729 - Flags: review?(bugs)
Could you please add test for the case when innerHTML is used in a not-in-document subtree. attachedCallback shouldn't be called in that case per spec.
The last patch causes one of the web-platform tests to fail. There is a test that is failing because of a slight difference in when the attach callback is enqueued. I've updated the patch so that the attached callback gets enqueued just before created callback invocation as per spec. I've also removed the code that enqueues the attached callback during element upgrade because it was removed from the spec some time ago and causes a double callback with these new changes. Also added the requsted test case.
Assignee: nobody → wchen
OS: Linux → All
Hardware: x86_64 → All
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.