You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking into this one, I have found that Aztec (Android) will cleanup the html it gets fed and remove spaces, when those are not important for HTML. Example: space chars at the beginning of <li>s content gets trimmed.
Those cleanups cause the text in RN and Aztec to get out of sync, with Aztec having a shorter text kept in its internal state. That's how Aztec crashes when RN tried to set the caret at the end of text, but that end is way beyond Aztec's text length.
If we employ the workaround from #835 (to silently set the caret position at end of text if asked to put it beyond it), the crash doesn't happen and editing can continue but, unexpected things also occur: the cleanup mutates the text beyond user's intentions while editing it. The user inputted space chars in the beginning of list items will get removed, automatically. Even if the user goes back and puts the spaces in again, tapping Enter to create a new list item anywhere in the list will re-do the cleanup, breaking user's edits.
I had a look at what happens in the other platforms, web and iOS:
Gutenberg web: the block editor doesn't even allow spaces to be inserted at the front of list items. It either swallows them or uses the space char as a shortcut to indent the list item.
iOS: it allows 1 space to stay and trims the rest (if multiple) and even keeps that 1 there when switching to html mode.
Adding extra spaces inside list blocks results in various crashes. I also observed similar issues when working on adding multiline image captions.
Test Scenarios
All of these crashes are pretty similar, so just including a gif of the first scenario (space-space-letter) as an example:
The text was updated successfully, but these errors were encountered: