Bug: Binding to webcomponent shadow root fails

[yuzuquats]

I'm working on converting lexical into an es6 module + webcomponent. I've been able to successfully bundle an es6 module (using webpack). Using it as a top-level component in the HTML document root works, but including it as a webcomponent doesn't.

Lexical version: 0.25

Steps To Reproduce

1. import a bundled lexical.bundle.min.js file
2. bind Lexical to an editor in the root DOM (ie. document.getElementById("editor")), and observe that it works
3. bind Lexical to an editor in the shadow DOM (this.shadowRoot.querySelector("#editor"), and observe that it doesn't work.

• The shadow dom's editor does receive attributes for data-lexical-editor=true among others
• The shadow dom does not receive key inputs

Link to code example:

Screen.Recording.2022-05-09.at.12.53.07.PM.mov

https://github.com/yuzuquats/lexical-web-component

Any help would be appreciated! I'm fairly new to npm so if there's anything obvious I'm missing I'd love to learn!

[trueadm]

That's strange. Lexical attaches the event listeners directly to the content editable (apart from selection, which is document level). Do you maybe have a codesandbox I could try?

[yuzuquats]

let me see if i can put together a code sandbox - the github should have a couple of quick steps to repro in the meantime.

In any case, I've done some digging and it seems like the root cause might be because we're using window.event. Specifically, I can confirm that key events (onBeforeInput) is called but the selection is null - thus early returning. In fact, it seems like selection is not actually being instantiated within the beginUpdate method. And this seems to be because the way we're grabbing the current active event is through window.event which is null/inaccurate for shadow trees.

I'm not sure if this is the only issue with webcomponent but it's the immediate reason why insertTextInput events are being swallowed.

[trueadm]

I had no idea that window.event is swallowed in shadow DOM. That's definitely problematic, and also concerning as we lean on it so much. Let me think about this.

[trueadm]

I attempted to fix this, can you maybe let me know if it works for you? #2126

[yuzuquats]

yup! i'll take a look

[yuzuquats]

const useDOMSelection =
    !getIsProcesssingMutations() &&
    (isSelectionChange ||
      eventType === "beforeinput" ||
      eventType === "compositionstart" ||
      eventType === "compositionend" ||
      (eventType === "click" && window.event.detail === 3) ||
      eventType == null);

useDOMSelection is still false here since getIsProcesssingMutations returns true

[yuzuquats]

I dove a little bit deeper:

• Even when useDOMSelection is true, lexical isn't able to resolve selection points for us (internalResolveSelectionPoints).
• This appears to be a consequence of the window.getSelection() returning seemingly inaccurate values for anchorDOM or focusDOM:
  • anchorDOM and focusDOM are being bound to the parent of the webcomponent and not the webcomponent or the webcomponent's internal contenteditable.
• As a result, the following lines fail:
  • rootElement.contains(anchorDOM)
  • rootElement.contains(focusDOM)
  • getNearestEditorFromDOMNode(anchorDOM) == editor

See 8ceb55a528cd7cba21987b68a92f9f80ba54cbb9

Next, I removed Lexical completely from the webcomponent and I can confirm that "onfocus" does indeed set all window.selection nodes to the container: 6933c895a04ea0b28aa9382b3f8c2cc25c585986

[yuzuquats]

FYI: seems like this might be a common problem and selection APIs across shadow DOM boundaries are being worked on

• Add shadow dom support slab/quill#1805
• Selection APIs for Shadow DOM WICG/webcomponents#79

In the meantime, I've opted to work around webcomponents with a simple class shim. Feel free to close this out unless you think there are better ways to work around this!

[trueadm]

Thanks for the comprehensive report and digging into the logic on this!

[thegreatercurve]

I'm going to close this task for the moment as the core ShadowDOM selection APIs are still being actively worked on. We the progress there. Plus, it'll be a while until we can add these new APIs into Lexical, once they are stabilised:

• getComposedRange() review w3c/selection-api#161

[johnstonmatt]

Support for Shadow DOM would be so awesome, building an editor as web component has a lot of potential!