Inline-editor component not working in chrome when contenteditable is inside a shadow dom

[lorefnon]

Affected part of DeckDeckGo

• Web Components

Affected web-component: inline-editor

Reproduction

Steps to reproduce:

1. Create a contenteditable inside a shadow-dom
2. Select text inside contenteditable
3. Click on any action in the editor toolbar

Expected Behavior

The action should update the html content inside contenteditable

Actual Behavior

It works as expected in firefox but not in chrome.

• Browser(s): chrome
• Operating System (e.g. Windows, macOS, Ubuntu): MacOS BigSur

Sandbox containing reproducer:

https://codesandbox.io/s/boring-jennings-hm2nf

---

It appears the problem is that document.getSelection() API returns the selection inside shadow-dom for firefox and in case of chrome, we get a fake selection where focusNode, range.startContainer, range.endContainer etc. are all body

[lorefnon]

One possible solution is to detect availability of ShadowRoot.getSelection method, and if supported we can find the nearest parent shadow root and call getSelection on it.

[peterpeterparker]

hi, thanks for the issue.

sounds like a good idea to use shadowroot.getSelection 👍. It might need more changes though as the DOM is custom manipulated (I don't use document.execCommand).

Would you like to give a try to solve the issue?

[lorefnon]

Sure @peterpeterparker Thanks for your reply.

I currently don't have much familiarity with the code but I'll see if I can explore and come up with a working PR over next 4-5 days.

I really love the UX of the component.

[peterpeterparker]

Awesome! Ping me if you have any questions or observations.

Source are there -> https://github.com/deckgo/deckdeckgo/tree/main/webcomponents/inline-editor

[lorefnon]

It might need more changes though as the DOM is custom manipulated (I don't use document.execCommand).

Ok, that actually creates a bigger issue for me because undo/redo does not work out of the box for styling changes (I just assumed that they would). So I'll need to check into managing undo stack at application level :\

[peterpeterparker]

Yes that's a drawback. I don't know what's the timeframe of the execCommand deprecation and when Input Level 2 will be introduced, so it's kind of a safe bet with custom code.

https://stackoverflow.com/questions/60581285/execcommand-is-now-obsolete-whats-the-alternative

[peterpeterparker]

Being said, maybe we can reintroduce execCommand and keep current implementation as backup plan. Open to discussion.

[lorefnon]

So one simple & minimal solution for the original problem is that we make displayTools an exposed method which consumers can call passing in a Selection which they have obtained from their own shadow root.

[peterpeterparker]

Sounds good to me. I'm afk, I'll review the PR later today or tomorrow.

[lorefnon]

Sure. Thanks @peterpeterparker .

[peterpeterparker]

Thanks a lot for the PR @lorefnon !

It has been merged and published to npm in version v3.4.0

[lorefnon]

Awesome thank you 🙂

[peterpeterparker]

@lorefnon FYI I just released v4.0.2 which re-introduces execCommand (default).

Optionally, through a property command the custom manipulation can be activated.

[lorefnon]

Nice :) Thank you. I know that execCommand is deprecated but given the platform's past track record it is very likely that it will outlive my hobby project.

[peterpeterparker]

Haha yes and in worst case, the custom implementation is still here ;)