Closed Bug 1093680 Opened 5 years ago Closed 5 years ago

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

Categories

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

36 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: lohentertainment, Assigned: wchen)

References

Details

Attachments

(1 file)

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.
Component: Untriaged → DOM
Product: Firefox → Core
Repro on 36.0a1 (2014-11-16) Win 7.
See the correct behavior in Chrome.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Fixed test case http://codepen.io/anon/pen/GgjJJM
(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?
Flags: needinfo?(wchen)
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
Flags: needinfo?(wchen)
Attachment #8544049 - Flags: review?(bugs)
Attachment #8544049 - Flags: review?(bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb1b266828a6
Assignee: nobody → wchen
Flags: in-testsuite+
OS: Windows 7 → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/fb1b266828a6
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.