1093680 - [Custom Elements] Nested custom elements doesn't importing properly

Status: RESOLVED FIXED

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

Description

[Luis Garcia]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36

Steps to reproduce:

Check out: http://codepen.io/anon/pen/dopzE


Actual results:

Nested custom elements imports not properly, if importing happens from parent to children, but properly from children to parent.


Expected results:

Nested custom elements should be imported in any order they are registered.

Comment 1

[Paul Silaghi, QA [:pauly]]

Repro on 36.0a1 (2014-11-16) Win 7.
See the correct behavior in Chrome.

Comment 2

[William Chen [:wchen]]

There are a few bugs here.

The first is that we don't currently call the created callbacks for nodes created by importNode. This is fixed in bug 1081039 and is going to be landing soon.

The second issue is that the linked test case looks like it has a bug, the closure captures the reference |char| and it looks like you actually want to it capture the value so it's probably not doing what you expect it to do.

The third bug is another gecko bug where we currently call the created callback (which in this case appends children) right after elements are created in the clone algorithm, before the clone children are appended. So even after the fix in bug 1081039, the resulting order of children is wrong. On the gecko implementation side, the fix is probably putting a script blocker on the stack before we start cloning nodes.

Comment 3

[Luis Garcia]

Fixed test case http://codepen.io/anon/pen/GgjJJM

Comment 4

[Andrew Overholt [:overholt]]

(In reply to William Chen [:wchen] from comment #2)
> The third bug is another gecko bug where we currently call the created
> callback (which in this case appends children) right after elements are
> created in the clone algorithm, before the clone children are appended. So
> even after the fix in bug 1081039, the resulting order of children is wrong.
> On the gecko implementation side, the fix is probably putting a script
> blocker on the stack before we start cloning nodes.

Do we have a bug filed for this?

Comment 5

[William Chen [:wchen]]

Attachment: Make sure there is a script blocker when cloning nodes.

No, I was going to use this bug for it.

The custom elements spec says to invoke callbacks just before returning control to script. The current implementation uses script blockers to stop callback from running too early, but it looks like there isn't a script blocker on the stack during node cloning. It seems to me that CloneAndAdopt should have a script blocker anyways so that script can't modify the original in the middle of cloning, although I'm not sure if script has an opportunity to run anywhere besides custom elements.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0d0fa408e9c9

Comment 6

[William Chen [:wchen]]

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

Comment 7

[Ryan VanderMeulen [:RyanVM]]

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