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

Categories

(DevTools :: Inspector, defect, P3)

65 Branch
defect

Tracking

(firefox68 fixed)

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 --- fixed

People

(Reporter: michael.england, Assigned: jdescottes)

References

Details

Attachments

(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: https://jsfiddle.net/michael_england/25dsnk48/

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-first-element>
<my-second-element slot="non-existing-slot"></my-second-element>
</my-first-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.

Status: UNCONFIRMED → NEW
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
Status: NEW → ASSIGNED
Flags: needinfo?(jdescottes)

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

See Also: → 1538325
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/650a3bd934c4
Update getDocumentWalker to fallback to non-anonymous walker;r=pbro
Status: ASSIGNED → RESOLVED
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.