[Android] Fix edge-cases when text leaf nodes are deleted #5325
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes edge-cases in the Android input manager when text leafs are deleted.
Issue
Fixes:
Context
Previously, text leaf deletions were stored in pending diffs and only reconciled when flushing as a result of a selection change or an action (such as inserting a line break). This could result in a number of different edge cases, such as the browser not knowing where to place the selection after deleting a text node before or after a void node.
In order to fix these edge cases, we detect when an input event would result in a text leaf being deleted, and schedule an action to allow Slate to reconcile its state with the DOM and apply normalization fixes (such as inserting zero-width spacers next to inline void nodes) rather than storing these events as deferred text diffs.
Example
Before
Screen.Recording.2023-02-28.at.4.06.09.PM.mov
After
Screen.Recording.2023-02-28.at.4.05.03.PM.mov
Note
There is a separate issue for the keyboard being closed when the selection moves right before void nodes, this PR does not solve that separate issue:
If we apply the fix described in the PR linked above, we can see what the final desired behaviour would eventually look like once we find a solution to #5183:
Screen.Recording.2023-02-28.at.4.09.53.PM.mov
Checks
yarn test
.yarn lint
. (Fix errors withyarn fix
.)yarn start
.)yarn changeset add
.)