Hello,
When ProseMirror throws an error, sometimes it takes editor into a state where page is unusable anymore, e.g. it keeps throwing RangeError no matter what user does. After working on a number of bugs coming from different plugins we started thinking about improving the errors logging and making editor more resilient.
Question 1: Can you confirm my understanding of ProseMirror internals that throwing a RangeError does not fully recover editor from a broken state, e.g. resets itself to a previous valid document and selection, or am I missing something?
If it doesn’t, would it make sense to introduce such behaviour inside ProseMirror?
Question 2: what would be your recommendations regarding improving traceability of destructive transactions? The goal here is to track down where (what plugin) transactions are coming from.
Currently we are logging stack trace, but it doesn’t help much in debugging, especially when the source code is minified.
A few examples:
Situation 1: tr.setSelection with invalid position
- it throws before we even able to catch (and potentially filter out/cancel) that with
filterTransactionordispatchTransaction
Situation 2:
tr.replace(from, to, content)
where from > to (clearly a coding error), which seems to be a perfectly valid operation that led to duplicating content.
filterTransaction helps here, but it doesn’t allow us to find the root cause (the exact place where such transaction gets dispatched).
Situation 3: a hidden bug(s) that causes a RangeError, which is temporarily fixed using appendTransaction and “repairing” the node, similar to what “fixTables” does. It would be nice to track down such bugs somehow, e.g. log current document structure, selection.
It would be very helpful if community could share some thoughts on that topic, if anyone attempted to implement monitoring + recovery already.