fix: 🐛 fix android soft keyboard dismisses when mark and input#6027
Open
virgil1996 wants to merge 1 commit into
Open
fix: 🐛 fix android soft keyboard dismisses when mark and input#6027virgil1996 wants to merge 1 commit into
virgil1996 wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: b8eb398 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
On Android, after toggling a mark (e.g. bold) with a collapsed selection, the next keystroke could dismiss the soft keyboard and break caret placement. The Android input manager scheduled a follow-up selection using a point computed as if the character were inserted inside the same text leaf (path unchanged, offset + text.length). When editor.marks is set, Editor.insertText uses insertNodes (a new marked text node) rather than extending the current leaf, so that computed point could lie beyond the leaf length and overwrite the valid selection that insertNodes had already applied.
This change stops scheduling a second Transforms.select with that raw point: performAction already normalizes action.at with normalizePoint and updates the selection; the previous run() callback duplicated the select with incorrect coordinates for the marks/insertNodes case.
Issue
Fixes: #6022
Example
Before repair see #6022
After repair:
https://github.com/user-attachments/assets/20d0d15a-687e-4816-9e8d-6b0de32fac05
Context
In handleDOMBeforeInput, after storeDiff for an insertion, the code called
scheduleAction(() => Transforms.select(editor, { anchor: newPoint, focus: newPoint }), { at: newPoint }). flush runsEditor.insertTextfor the diff; with active marks, Slate’s insertText inserts a new text node and sets the selection to the end of that node. performAction then runs: it first selects usingnormalizePoint(editor, newPoint), which maps an “past end of leaf” offset onto the correct following text node. Immediately after,action.run()calledTransforms.selectagain with the un-normalized newPoint, which is invalid when the insert was a sibling node. Replacing the callback with a no-op keeps selection handling solely in the normalizePoint path inside performAction.Checks
yarn test.yarn lint. (Fix errors withyarn fix.)yarn start.)yarn changeset add.)