[Comments] react-editor crash when writing diacritics

[Matjaž Horvat]

This issue was created automatically with bugzilla2github.

Bug 1713496

Bug Reporter: @MikkCZ
CC: @Pike

STR:

1. Open any string, e.g. https://pontoon.mozilla.org/cs/firefox/all-resources/?string=74127.
2. Open the comment textarea either on a suggestion or the string in general.
3. On Czech keyboard do two times:
   -- press acute/caron key (with or without Shift), followed by e.g. E, to write either "é" or "ě"
   -- press space bar

What should happen:

• The area should contain "é é " or "ě ě " depending on what you pressed.

What happens:

• The first time space is pressed, the letter disappears. The second time the whole frontend crashes and two errors appear in the console.

Error: Cannot resolve a DOM point from Slate point: {"path":[0,0],"offset":3}
    toDOMPoint react-editor.ts:262
    toDOMRange react-editor.ts:277
    wt editable.tsx:184
    React 3
    unstable_runWithPriority scheduler.production.min.js:19
    React 4
    unstable_runWithPriority scheduler.production.min.js:19
    React 4
    onChange with-react.ts:177
    apply create-editor.ts:86
    promise callback*apply create-editor.ts:84
    apply with-react.ts:52
    insertText text.ts:448
    withoutNormalizing editor.ts:1587
    insertText text.ts:414
    insertText create-editor.ts:188
    insertText editor.ts:319
    onBeforeInput editable.tsx:498
    React 12
    unstable_runWithPriority scheduler.production.min.js:19
    React 13
    unstable_runWithPriority scheduler.production.min.js:19
    React 4
    Redux 5
    a middleware.js:22
    dispatch Redux
    r actions.js:67
    h runtime.js:63
    _invoke runtime.js:293
    S runtime.js:118
    Babel 2
react-dom.production.min.js:209:194

Uncaught (in promise) Error: Cannot resolve a DOM point from Slate point: {"path":[0,0],"offset":3}
    toDOMPoint react-editor.ts:262
    toDOMRange react-editor.ts:277
    wt editable.tsx:184
    React 3
    unstable_runWithPriority scheduler.production.min.js:19
    React 4
    unstable_runWithPriority scheduler.production.min.js:19
    React 4
    onChange with-react.ts:177
    apply create-editor.ts:86
    promise callback*apply create-editor.ts:84
    apply with-react.ts:52
    insertText text.ts:448
    withoutNormalizing editor.ts:1587
    insertText text.ts:414
    insertText create-editor.ts:188
    insertText editor.ts:319
    onBeforeInput editable.tsx:498
    React 12
    unstable_runWithPriority scheduler.production.min.js:19
    React 13
    unstable_runWithPriority scheduler.production.min.js:19
    React 4
    Redux 5
    a middleware.js:22
    dispatch Redux
    r actions.js:67
    h runtime.js:63
    _invoke runtime.js:293
    S runtime.js:118
    Babel 2
react-editor.ts:262:12

[Matjaž Horvat]

Comment Author: @MikkCZ

Created attachment 9224166
screen recording.webm

Attached file: Nahrávka obrazovky z 30.5.2021 11:50:27.webm (video/webm, 1206739 bytes)
Description: screen recording.webm

[Matjaž Horvat]

Comment Author: @MikkCZ

Observation, the "offset" in the error message differs based on what you write. This happens in the middle of the text as well.

Also when you use the keys in the row below F-keys, which by default in Czech layout write "ěščřžýáíé", directly, everything works. But note, this is only a partial workaround, because not all letters with diacritics can be written like that.

[Matjaž Horvat]

Comment Author: @Pike

Can you test this on https://www.slatejs.org/examples/mentions? Maybe this is an upstream bug.

[Matjaž Horvat]

Comment Author: @MikkCZ

I wasn't able to reproduce it there, however I see that mozilla#1955 updated slate, and in the issue tracker of slate there is a ton of bugs (some specific to Firefox) that it does not handle the cursor position properly under all conditions.

In this specific case and after looking at the error message in more detail, I guess something looses the information about number of characters being actually typed. When you start by pressing the acute/caron key (with or without Shift), ´ or ˇ appears, and is then merged with what's written next. That's normal behaviour. But if the library or frontend code does not account for that, it will definitely cause an index to go out of bounds of the text actually written in the area.