Closed Bug 1102502 Opened 6 years ago Closed 6 years ago

[Custom Elements] attachedCallback does not seem to be called when a custom element is added using innerHTML


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: julienw, Assigned: wchen)



(3 files, 2 obsolete files)

I found this while working on gaia-header tests [1].

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?


NI Guillaume who volunteered to produce a smaller testcase.
Flags: needinfo?(gmarty)
The reduced test case is here:

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.
Flags: needinfo?(gmarty)
Flags: needinfo?(wchen)
I think this is a chrome bug. I've filed it here:

Although, this may be behavior that we may want to change in the spec.
Flags: needinfo?(wchen)
I agree that attachedCallback should not be called before createdCallback, but it should be called after createdCallback, don't you think?
Attached file testcase-component-lifecycle.html (obsolete) —
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...
Flags: needinfo?(wchen)
This is a spec bug:

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." [1]

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.

Flags: needinfo?(wchen)
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.
Attachment #8538729 - Flags: review?(bugs) → review+
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.
Attachment #8538729 - Attachment is obsolete: true
Attachment #8539660 - Flags: review?(bugs)
Attached patch v1diffv2.patchSplinter Review
Attachment #8539660 - Flags: review?(bugs) → review+
Assignee: nobody → wchen
Flags: in-testsuite+
OS: Linux → All
Hardware: x86_64 → All
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.