Debugging some EditorView errors

Hi there! After using CM6 in a production beta of our app for the last few weeks+, I’ve noticed a handful of errors originating in codemirror/view in our error-tracking system, but I haven’t been able to reproduce the issues reliably so I wanted to post here to see if anything sticks out about them that might help us debug / understand if we’re doing something wrong with EditorViews (rather than open issues in codemirror.next).

It seems that often one or more happens around the same time as another, and not all, but a considerable number of instances of these errors seem to occur when an EditorView is about to be destroyed, it’s blurred, or focus position changes within it. I’m wondering if perhaps we’ve set up something incorrectly when EditorViews are being destroyed, or if you think something else might be going on here. Thanks so much again for all your help in advance.

1 Like

Hi. Many of these suggest that the editor’s internal data structures (specifically the view tree) have been corrupted at some point before the error occurs, so the stack traces probably don’t point at the code where the problem is. Could you say a bit more about what is happening when the editors are being destroyed? I tried to set up some scenarios where editors were hidden and destroyed, but didn’t manage to trigger any errors like this.

Thanks @marijn – I’ve had difficulty reproducing the bugs as well by replicating scenarios that I thought could cause them… there doesn’t seem to be any consistency in the browsers used (I’ve seen Chrome, Safari, Firefox, Edge). I think our flow for destroying EditorViews is fairly standard for what one would do in a React app: when the component which serves as the parent element for the EditorView is unmounted, we call EditorView.destroy. This happens specifically in the cleanup portion of a useEffect hook. I think this sequence of events should be fine, given that “the clean-up function runs before the component is removed from the UI” according to the React docs, but it does seem like a good portion of the errors come immediately after an EditorView is being removed from the DOM. That said, I could be totally off – curious if you think there are other likely or common causes of this sort of corruption of the view tree (perhaps a problematic view plugin we’ve written?) or have ideas of other things I should try to debug this further? Thanks again. :pray:

This is more likely to be a bug in the library somewhere. In principle, extensions should not be able to corrupt the editor’s internal view tree. But without a way to reproduce this, I can only guess. I tried to set up a crude fuzzer to just hit the editor with random transactions for a bit to see if something breaks, but still didn’t find anything.

Got it – I’ll work on gathering more information around the sequences of events that lead to these errors and hopefully figure out how to reproduce them. Thanks for trying!!

We have the first error in a angular application. It is really hard to reproduce as it only happens on a specific window size and when there is a bigger text copied into the editor. Unfortunately I was not able to reproduce it in an example application.