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

List crashes with extra spaces #871

Closed
mchowning opened this issue Apr 15, 2019 · 1 comment · Fixed by #885
Closed

List crashes with extra spaces #871

mchowning opened this issue Apr 15, 2019 · 1 comment · Fixed by #885

Comments

@mchowning
Copy link
Contributor

mchowning commented Apr 15, 2019

Adding extra spaces inside list blocks results in various crashes. I also observed similar issues when working on adding multiline image captions.

Test Scenarios

  1. (1) Begin editing new list, (2) add two spaces, (3) add any letter, (3) press Enter, and 💥
  2. (1) Begin editing new list, (2) add three spaces, (3) press Enter, and 💥
  3. (1) Begin editing new list, (2) add any letter, (3) add three spaces (second space creates a period), (4) press Enter, and 💥

All of these crashes are pretty similar, so just including a gif of the first scenario (space-space-letter) as an example:
output_spacespace

@hypest
Copy link
Contributor

hypest commented Apr 17, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants