ReferenceError: Potentially corrupt editorState

mirkolenz commented 2 years ago

I am using this library in a larger app called ArgueMapper. For some reason, I am unable to update the text of the underlying text field externally. To illustrate this, I added a "Debug" Button that appends the string Hello to the value of the text field. If I do this twice, the app crashes with the error ReferenceError: Potentially corrupt editorState. You can try it out yourself on the published version. To illustrate this even better, I made a short video:

https://user-images.githubusercontent.com/5160954/183655898-6675bd3c-e7ae-4a06-8665-7ed060f9b13d.mp4

Here is some information that may be relevant for further investigation:

My implementation of the text field. I also tried it without wrapping it as a Material UI component, but nothing changed.
The action of the debug button
I use Zustand for managing state
The error is thrown here
Using the Chrome debugger I found out that in all cases where the exception is thrown, anchorKey and anchorKey are empty. I was not able to find the root cause of this issue.

I am thankful for any kind of help.

bonafideduck commented 2 years ago

I don’t see inputProps being sent a value or onChange handler. Also, I’d leave off the selection initially. RHWTA selection may not be what you are expecting.

mirkolenz commented 2 years ago

Thank you for the quick response. I tried different configurations, for example this one as a minimal example:

<HighlightWithinTextarea
  value={resource.text}
  onChange={onChange}
/>

Even in this configuration, the error occurs. What seems strange to me is that this always happens after the second click.

I don’t see inputProps being sent a value or onChange handler.

This is caused by the way that MUI implemented third-party text fields. The onChange handler and the value are passed to the parent component and then passed down internally to the third-party text field.

kazimirchuk commented 2 years ago

@mirkolenz I stumbled upon the same error and the solution I found was to downgrade the react-highlight-within-textarea to the version 2.2.0 and it started working nicely. Behind the scenes they depend on the same version of draft-js so I would assume something is wrong with the latest version. Not sure if there are any issues with 2.2.0 version comparing with the latest one though. Hope this helps 👍

mirkolenz commented 2 years ago

@kazimirchuk Indeed, that fixed it for me too. The only downsides are that v2.2.0 has no explicit support for React 18 and that the draft-js props are not forwarded. Thank you very much for your suggestion!

bonafideduck commented 2 years ago

Awe gee, now I can’t blame it on operator error. If there is a simple reproduction of this in codepen or similar, I’d appreciate it. Otherwise, I’ll debug eventually.

mirkolenz commented 2 years ago

I will try to come up with a reproduction of this.

bonafideduck commented 2 years ago

🙏

mirkolenz commented 2 years ago

Here is a reproducible and minimal example of this error: https://codesandbox.io/s/rhwta-issue-157-23vjzc

It is perfectly fine to change the text manually however you like. But if you hit the button Add Text twice, the error is shown.

bonafideduck commented 2 years ago

@mirkolenz , thank you for the issue. I think I have a fix and will have it out hopefully soon (at least by next weekend).

Root cause: I assumed there would always be an anchor and selection returned from draftjs's editorState. But if the editor doesn't have focus, it will not. You can see this by clicking in the editor each time before clicking "Add Text". It doesn't crash then.

mirkolenz commented 2 years ago

@bonafideduck Thank you for the feedback. The root cause seems plausible to me. Still kind of strange that this behavior does not happen for v2.2.0 of this library. I skimmed over the relevant source code and it seems to be equal to me.

bonafideduck commented 2 years ago

@mirkolenz , that is a great point. I see that i changed a block.key to a block.getKey(). Maybe that is not working as expected. I’ll research it in the future. (Hopefully tomorrow)

bonafideduck commented 2 years ago

@mirkolenz

Morning debug results:

If there is no focus, selection.getAnchorKey() returns '' which is not a key.
My 2.2.0 version somehow recaptures focus, so this is not an issue.

Going forward:

I'll definitely have to handle the getAnchorKey()=>'' issue as it is a valid return.
I need to dig into if 2.2.0 is incorrectly grabbing focus or 3.x.x should be.

I may push a fix for the '' return soon (hopefully tonight) and then dig into the focus issue.

mirkolenz commented 2 years ago

@bonafideduck Thank you for the insights! Your debug results mimic my observations. Using the Chrome debugger, I also noticed that the keys being an empty string was the problem condition. And great to hear that you will provide an update in such a short amount of time 😄

Regarding the focus: My intuition would be that the editor should not grab focus. The bug will most likely occur if one is modifying the text externally.

For instance in my app, the text is stored in a global state that has undo/redo support. If I undo an action, the editor text is only one part and as such should not be focused afterwards. The user would expect no "context switch" in my use case.

bonafideduck commented 2 years ago

@mirkolenz , this has been pushed to version 3.1.1.

mirkolenz commented 2 years ago

@bonafideduck Thank you, the fix works as expected for my use case 😄

bonafideduck / react-highlight-within-textarea

ReferenceError: Potentially corrupt editorState #157