1515518 - XBL <children/> cannot be slotted into Shadow DOM: Assertion failure: !content->IsActiveChildrenElement(), at /builds/worker/workspace/build/src/layout/base/RestyleManager.cpp:3033

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Please see the attached test case. It's a mixed-use of XBL binding, custom element, and shadow dom.

The desired effect is that the <label value="5"/> node on the document will be slotted into <children/>, and it in term will be slotted into the light DOM under the shadow DOM attached to <xul:shadowdom-element>. So everything will render in order (1 2 3 4 5).

The page crashes, however, after the JS inspects all the DOM nodes.

I am reusing the test case I made for bug 1470242 so not all ok() is related here.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Bug 1515518 test case

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I made the same setup in bug 1454357 comment 6. The binding there will be removed altogether, so I am moving the issue to this bug with an artificial test case instead.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

It doesn't surprise me that this does not work. I don't think we should complicate the code to make it work tbf, unless it's a huge blocker for you.

The interaction between XBL and Shadow DOM is scary at best.

Comment 4

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

yeah, I think we should explicitly not support something like this.

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to Olli Pettay [:smaug] (away-ish Dec 21-30) from comment #4)
> yeah, I think we should explicitly not support something like this.

OK. It will make XBL replacement more difficult, but I understand.

We'll have to put off using Shadow DOM until all hosts for that element never slot in any node that uses XBL <children />. And since there's a web of dependencies of components using other components, I think we'll have to selectively choose a few bindings where we more or less need SD, and wait to do them last.

From previous discussions, I think that would be at least: `panel`, `tree`, `wizard`, possibly `richlistbox`.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am uploading two more tests on the same differential.

The good news is the other way around works, i.e. try to construct an XBL binding from shadow dom and expects the bound element to be moved to <children>. I am using .style.MozBinding here I don't know if that makes any different.

The third test tries to migrate <content> to shadow DOM in XBL constructor. attachShadow() simply throws with InvalidStateError :'(.

Comment 7

[Neha Kochar [:neha]]

Olli/Emilio/Tim, what's the consensus here?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

The third test tries to migrate <content> to shadow DOM in XBL constructor. attachShadow() simply throws with InvalidStateError :'(.

I cannot even think what having both an XBL binding and shadow dom means in terms of what should show up in the flattened tree, thus why we disallow it.

(In reply to Neha Kochar [:neha] from comment #7)

Olli/Emilio/Tim, what's the consensus here?

It looks like everyone is fine with WONTFIX, but pleas reopen if it's not the case.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yeah, Brian and I talk through the remaining binding. It seems that this bug only affects the use of CE-with-shadow-dom elements inside XBL <content>. We should be able to continue the de-XBL work by carefully figure out the order of XBL-CE conversion.