Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CKEditor: handle being torn down before initialization #383

Closed
wants to merge 1 commit into from

Conversation

kyrofa
Copy link

@kyrofa kyrofa commented Jun 2, 2023

It's easy, particularly in tests, to end up rendering the editor only to then quickly change a prop that causes it to no longer render. It's possible for this to happen quickly enough that _initializeEditor() hasn't finished running yet, thus ending up in _createEditor() with a null element. That ends up causing CKEditor itself to throw an exception, and ends up not defining the editor, which then makes the watchdog throw an exception. The latter error is not catchable in an error boundary due to its asynchronous nature.

Fix this by making _createEditor() a little more defensive: make sure we have an element before bothering to create an editor. If we don't have one, we know we're in the midst of a teardown, so create a dummy editor so the watchdog has something to destroy.

This might be related to #351, but I'm not certain.

It's easy, particularly in tests, to end up rendering the editor only to
then quickly change a prop that causes it to no longer render. It's
possible for this to happen quickly enough that `_initializeEditor()`
hasn't finished running yet, thus ending up in `_createEditor()` with a
null `element`. That ends up causing CKEditor itself to throw an
exception, and ends up not defining the editor, which then makes the
watchdog throw an exception. The latter error is not catchable in an
error boundary due to its asynchronous nature.

Fix this by making `_createEditor()` a little more defensive: make sure
we have an element before bothering to create an editor. If we don't
have one, we know we're in the midst of a teardown, so create a dummy
editor so the watchdog has something to destroy.

Signed-off-by: Kyle Fazzari <[email protected]>
@Witoso Witoso added squad:core Issue to be handled by the Core team. and removed squad:core Issue to be handled by the Core team. labels Jun 7, 2023
@Witoso
Copy link
Member

Witoso commented Jun 7, 2023

@pomek will your team take a look?

@kyrofa
Copy link
Author

kyrofa commented Aug 17, 2023

FYI, I did sign the CLA, not sure why your system thinks I haven't.

Screenshot from 2023-08-17 10-14-56

Just in case you're waiting for that to review this, @pomek.

@Witoso
Copy link
Member

Witoso commented Aug 18, 2023

@vokiel could you check if it's signed?

@vokiel
Copy link

vokiel commented Aug 18, 2023

Check, all good ✔️

@kyrofa
Copy link
Author

kyrofa commented Oct 12, 2023

Any chance someone could take a look at this? @pomek, friendly ping.

leadegroot added a commit to uqlibrary/fez-frontend that referenced this pull request Nov 27, 2023
@Mati365
Copy link
Member

Mati365 commented Jul 5, 2024

@Witoso / @kyrofa This PR can be closed. We fixed this issue here, released in 7.0.0 version.

@pomek
Copy link
Member

pomek commented Aug 26, 2024

Closing due to #383 (comment).

@pomek pomek closed this Aug 26, 2024
@kyrofa kyrofa deleted the bugfix/handle-no-dom-element branch August 26, 2024 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants