[Comments] react-editor crash when writing diacritics

[mathjazz]

This issue was created automatically by a script.

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

[mathjazz]

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

[mathjazz]

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.

[mathjazz]

Comment Author: @Pike

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

[mathjazz]

Comment Author: @MikkCZ

I wasn't able to reproduce it there, however I see that https://github.com/mozilla/pontoon/pull/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.