Bug 188284 - Custom elements created by the parser in a connected position have their constructors and connectedCallbacks called out of order
Summary: Custom elements created by the parser in a connected position have their cons...
Status: RESOLVED DUPLICATE of bug 188189
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari 11
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-08-02 16:32 PDT by Russell Bicknell
Modified: 2018-08-14 15:36 PDT (History)
6 users (show)

See Also:


Attachments
A page with custom elements that log when their constructor and connectedCallback are called. (754 bytes, text/html)
2018-08-02 16:32 PDT, Russell Bicknell
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Russell Bicknell 2018-08-02 16:32:38 PDT
Created attachment 346427 [details]
A page with custom elements that log when their constructor and connectedCallback are called.

When a group of custom elements are created through the parser (either because they are in the main document's HTML or are in a string being set to a connected element's `innerHTML` property), they are all constructed before any have their `connectedCallback` called.

For example, for this tree:

<c-e id="A">
  <c-e id="B"></c-e>
</c-e>
<c-e id="C"></c-e>

Safari calls the constructor and connectedCallback of each in this order:

- constructor A
- constructor B
- constructor C
- connectedCallback A
- connectedCallback B
- connectedCallback C

However, the order should be this:

- constructor A
- connectedCallback A
- constructor B
- connectedCallback B
- constructor C
- connectedCallback C


Relevant spec text:
https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token

The 'in-document HTML' case would have 'will execute script' set to true, meaning that the interleaved order above is the expected order, AFAICT.

I think Safari's `innerHTML` is correct here though: it would have 'will execute script' set to false, so the connectedCallback reactions would all be delayed until they're popped at the end.
Comment 1 Russell Bicknell 2018-08-02 17:22:26 PDT
Chrome and Firefox seem to have the opposite problem; their `innerHTML` setters act as if the elements being created were in the main document:
https://bugs.chromium.org/p/chromium/issues/detail?id=870512
https://bugzilla.mozilla.org/show_bug.cgi?id=1480632
Comment 2 Ryosuke Niwa 2018-08-04 22:06:14 PDT
Do we have any WPT tests that cover these cases?
Comment 3 Frédéric Wang (:fredw) 2018-08-05 00:44:47 PDT
For the synchronous case ('in-document HTML'), the patch on bug 188190 is supposed to force execution of the connectedCallBack immediately after insertion of the element (There is WPT test to ensure the element is indeed empty when connectedCallBack is called). That might improve things, but I don't know beforehand what we do regarding the order of constructor call / element insertion, especially since HTMLConstructionSite uses an m_taskQueue to delay insertion.
Comment 4 Russell Bicknell 2018-08-06 14:53:45 PDT
(BTW, the other two bugs I mentioned are now closed: my interpretation of the spec was wrong.)
Comment 5 Radar WebKit Bug Importer 2018-08-06 17:01:22 PDT
<rdar://problem/42987289>
Comment 6 Frédéric Wang (:fredw) 2018-08-07 00:56:30 PDT
(In reply to Russell Bicknell from comment #4)
> (BTW, the other two bugs I mentioned are now closed: my interpretation of
> the spec was wrong.)

Thanks for the update. For the non-synchronous case (innerHTML) note that bug 188327 was recently fixed.
Comment 7 Ryosuke Niwa 2018-08-14 15:36:28 PDT
Okay, this is caused by the bug 188189 so I'll fix it there.

*** This bug has been marked as a duplicate of bug 188189 ***