Closed Bug 1102502 Opened 5 years ago Closed 5 years ago

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

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: julienw, Assigned: wchen)

Details

Attachments

(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?

[1] https://github.com/gaia-components/gaia-header

NI Guillaume who volunteered to produce a smaller testcase.
Flags: needinfo?(gmarty)
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.
Flags: needinfo?(gmarty)
Flags: needinfo?(wchen)
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.
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: 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." [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.

[1] http://w3c.github.io/webcomponents/spec/custom/#types-of-callbacks
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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/af30b02139ef
Assignee: nobody → wchen
Flags: in-testsuite+
OS: Linux → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/af30b02139ef
Status: NEW → RESOLVED
Closed: 5 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.