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

Status: RESOLVED FIXED

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

Description

[Julien Wajsberg [:julienw]]

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.

Comment 1

[Guillaume Marty [: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.

Comment 2

[William Chen [: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.

Comment 3

[Julien Wajsberg [:julienw]]

I agree that attachedCallback should not be called before createdCallback, but it should be called after createdCallback, don't you think?

Comment 4

[Julien Wajsberg [:julienw]]

Attachment: testcase-component-lifecycle.html

Comment 5

[Julien Wajsberg [:julienw]]

Attachment: testcase-component-lifecycle.html

Looks like Firefox removes web components from the source when using ctrl-S to save a page...

Comment 6

[Julien Wajsberg [:julienw]]

Hey William, can we move forward here? It's really painful that the attachedCallback callback is not called when using innerHTML...

Comment 7

[William Chen [:wchen]]

Attachment: Fire custom elements attachedCallback when elements are created and inserted into the document by the parser.

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

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 9

[William Chen [:wchen]]

Attachment: Fire custom elements attachedCallback when elements are created and inserted into the document by the parser. v2

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.

Comment 10

[William Chen [:wchen]]

Attachment: v1diffv2.patch

Comment 11

[William Chen [:wchen]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/af30b02139ef

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/af30b02139ef