Closed Bug 1537877 Opened 6 months ago Closed 6 months ago

Custom element a with slot attribute who has a parent without a matching slot tag breaks viewing of descendants in the inspector


(DevTools :: Inspector, defect, P3)

65 Branch


(firefox68 fixed)

Firefox 68
Tracking Status
firefox68 --- fixed


(Reporter: michael.england, Assigned: jdescottes)




(2 files)

Attached image missing-nodes

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15

Steps to reproduce:

It seems you can't inspect a custom element's children or shadow root when there is a child custom element that wants to be slotted to a non-existenting slot tag. We ran into this scenario because we have a few layout elements that will render a slot depending on some state of the component. Here's a jsfiddle demonstrating the behavior:

1.) Create two custom elements such as the following:

customElements.define('my-first-element', class extends HTMLElement {
connectedCallback() {
this.attachShadow({mode: 'open'})
this.shadowRoot.innerHTML = '<div>foo-bar, I can't be found in dev tools</div>'

customElements.define('my-second-element', class extends HTMLElement {
connectedCallback() {
this.attachShadow({mode: 'open'})
this.shadowRoot.innerHTML = '<div>second-element</slot.'

2.) Compose them like:

<my-second-element slot="non-existing-slot"></my-second-element>

3.) Open inspector
4.) Can't view descendants or shadow root of my-first-element

Actual results:

You can't view descendants or shadow root of my-first-element

Expected results:

You should be able to view children and shadow root.

Ever confirmed: true
Flags: needinfo?(jdescottes)
Priority: -- → P3

@jdescottes I am told you will know what is going on here.

Thanks for the report, will take a look!

Assignee: nobody → jdescottes
Flags: needinfo?(jdescottes)

Except for rawParentNode, all consumers of getDocumentWalker should be ok with this fallback.

See Also: → 1538325
Pushed by
Update getDocumentWalker to fallback to non-anonymous walker;r=pbro
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

I'm wondering if the changes have a shared code path with WebDriver/Selenium, or if there is a way to find out if it does? Our QE has tests that fail unless we remove the offending child element or we run the test using the nightly (FF68), which has this fix. If it does have a shared path, anyway we can get this back ported to 65? Thanks!

You need to log in before you can comment on or make changes to this bug.