fix(synthetic-shadow): Fix API interaction with light DOM components #2393
Conversation
| expect(nodes.p.parentElement).toEqual(nodes.consumer); | ||
| }); | ||
| xit('getRootNode', () => { | ||
| expect(nodes.p.getRootNode()).toEqual(document); |
There was a problem hiding this comment.
I remember we had a discussion about owner keys during a dev sync but I don't remember the details. Did we say that Light DOM components should inherit owner keys? I guess we could get this working if we did?
There was a problem hiding this comment.
It's a little more complex than this. Node.prototype.getRootNode fails when a light DOM element is the top-level light DOM element because there is no owner key to inherit from.
| ); | ||
| }); | ||
| xit('innerHTML', () => { | ||
| expect(nodes.consumer.innerHTML).toEqual( |
There was a problem hiding this comment.
This returns an empty string with synthetic shadow--is that because the slotted content has no associated owner key?
pmdartus
force-pushed
the
pmdartus/light-dom-assigned-elements
branch
from
18467ea
to
69512bf
Compare
|
@ekashida I am not planning to fix the new bugs I uncovered as part of this PR, I created dedicated issues for each bug. |
There was a problem hiding this comment.
(dismiss my previous request for change) This does LGTM. Just a note: This change may have perf implications in the platform. IIRC, in the platform, .parentNode is part of the critical path because Aura uses it to render aura components. and isSlotElement does node instanceof HTMLSlotElement.
Details
This PR fixes incorrect behavior when light DOM components are used with synthetic shadow DOM:
HTMLSlotElement.prototype.assignedNodesandHTMLSlotElement.prototype.assignedElementson shadow slots and light DOM slotted content.Node.prototype.parentNodeandNode.prototype.parentElenenton light DOM slotted content inside a shadow DOM component.Fix #2386
Does this PR introduce breaking changes?
No, it does not introduce breaking changes.The PR fulfills these requirements: