Closed Bug 1515518 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: timdream, Unassigned)

References

Details

Attachments

(1 obsolete file)

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.
Attached file Bug 1515518 test case (obsolete) (deleted) —
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.
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.
yeah, I think we should explicitly not support something like this.
(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`.
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 :'(.

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

Flags: needinfo?(timdream)
Flags: needinfo?(emilio)
Flags: needinfo?(bugs)

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.

Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(emilio)
Resolution: --- → WONTFIX

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.

Flags: needinfo?(timdream)
Attachment #9032570 - Attachment is obsolete: true
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: