decorated text cannot be selected (#3118 re-open)

[jege31]

Issue #3118 was unfortunately not corrected by #3093, so I open this new issue, as suggested.

I wrote a new index.jsx (renamed index.txt because github does not accept .jsx) compliant with the new architecture of Slate.
The behaviour remains the same : after rendering a decoration (that looks ok in the browser) the text cannot be selected anymore. The cursor automatically moves to the end of the text. (see screen record #3118)
Moreover, when the cursor reaches the end of the text, the script raises an error : "Error: Cannot resolve a DOM point from Slate point: {"path":[0,0],"offset":33}"

The browser is Firefox and Slate is 0.53.0

[stevez86]

I was just about to post an issue related to this, not sure if its related to selecting decorated text. I get the following errors very frequently:

Cannot resolve a Slate point from DOM point: [object HTMLLIElement],0
Cannot resolve a DOM point from Slate point: {"path":[0,1,0],"offset":106}

It sometimes happens after a user clicks in the editor. I know this from my error reporting which reports clicks.

I can't reproduce yet, (only noticing in analytics) but it seems to happen more frequently (but not entirely) with mobile Android devices, (including Chrome Mobile 77.0.3865, Amazon Silk 73.7.5, Mobile Safari 13.0.3, Chrome Mobile 78.0.3904).

I've had this occur on 0.50, 0.52 and 0.54. (I keep updating hoping this issue will resolve)

I'll keep trying to reproduce and update as I find more information.

[jege31]

I think there are 2 issues.
1 issue (this #3309) concerning the selection of decorated text. This issue was already existing (#3118) before the slate refactoring.
1 issue concerning the raised error "Cannot resolve a DOM point from Slate point" (and "Cannot resolve a Slate point from DOM point"). This one is new since the slate refactoring.

Since the Slate refactoring, the 1st issue when selecting of decorated text, also leads to raise the 2nd issue.

[jege31]

I've inserted a GIF.
There was already a sandbox : index.jsx

[mattapperson]

Also having this issue

[jege31]

I found a work-around, setting "contentEditable={false}" for the decoration elements.

const Leaf = ({ attributes, children, leaf}) => {
  const style = { backgroundColor: "lightcoral" };

  if (leaf.mydec) {
    return (
      <span {...attributes}>
        <span style={style} contentEditable={false}>Deco</span>
        <b>{children}</b>
      </span>
    );
  }
  return <span {...attributes}>{children}</span>;
};

[roshan1894]

+1, I am getting similar error. Details on this:

Description:
This error is thrown when I add a custom link into a slate editor at current cursor position and use tab or space after the inserted link.

Recording:
https://user-images.githubusercontent.com/86764119/146716602-657bf5ce-535a-4bdb-bb36-64c3fbb8d548.mp4

Expectation:
We have a script which attaches our custom icon to the outreach email editor and apparently outreach email editor uses slate editor. After clicking upon this icon, it opens our extension application in a new tab[for now]. If user clicks on "INSERT LINK" button, link should be inserted at current cursor position which is happening as expected. But, I am unable to click the link and write any texts further after the insertion. If I use space or tab after the link insertion, this error shows up. You could see this clearly in the attached video.

Environment:

Slate Version: No idea as this is happening in third party website
Operating System: Windows
Browser: Chrome

[rafaelhrtd]

This problem is ongoing.

[jackmcintire]

The problem persists

[mcd92]

The problem remains

[VladosusCocosus]

The same problem occurred last 3 week

[markacola]

This error occurs for me during the Editable useIsomophicLayoutEffect call after a rerender causes a previous selection to no longer exist/be outside the re-rendered content.
e.g. A user has 567 selected in 1234567 and a rerender forces 1234 to be rendered.

This causes setDomSelection to be called, where the subcalls to ReactEditor.toDOMRange and subsequently ReactEditor.toDOMPoint fail to resolve the selection via the dom, as the element with that offset no longer exists.

I think the fix here would be to either:

1. Extends ReactEditor.toDOMRange to have a suppressThrow option so it can return null as is expected in the subsequent lines, or
2. Extend the preceeding conditional to check if the dom doesn't have the range, and if so collapse the selection.