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

Fix caret position after inline paste - is broken #903

Closed
marecar3 opened this issue Apr 19, 2019 · 5 comments · Fixed by #995
Closed

Fix caret position after inline paste - is broken #903

marecar3 opened this issue Apr 19, 2019 · 5 comments · Fixed by #995
Assignees
Labels
[Type] Bug Something isn't working

Comments

@marecar3
Copy link
Contributor

marecar3 commented Apr 19, 2019

As @mkevins reported :

After inline paste, the caret position should be "incremented" by the length of the inserted text. This is set explicitly during the paste handling via the forceSelectionUpdate method. A safety check was added to the render method to prevent an out of bounds exception that can occur when the caret is moved to a position that is larger than the text buffer, which may happen as a result of Aztec trimming spaces in the content.

For the purpose of checking this condition, the willTrimSpaces method https://github.com/WordPress/gutenberg/pull/15021/files#diff-4828a21853e899e5a36faecfa96d83e8R631 was introduced, which tries to evaluate whether Aztec will trim spaces, and if so, prevents setting the caret position. The regex that looks for outer spaces (that will be trimmed) also matches on any spaces adjacent to html tags (including inner tags). The result is that whenever the html contains inner tags adjacent to spaces (e.g. a bold word), the caret will not be in the correct position after paste.

@marecar3 marecar3 added the [Type] Bug Something isn't working label Apr 19, 2019
@marecar3 marecar3 added this to the v1.3 milestone Apr 19, 2019
@marecar3
Copy link
Contributor Author

Hey, @hypest @mkevins I have opened the issue regarding regression that @mkevins has mentioned.

@koke
Copy link
Member

koke commented Apr 30, 2019

Sorry, it's not very clear to me what the issue is, so it's hard to prioritize. Can you edit the description in terms of what is broken and adding steps to reproduce and screenshot/gif/video (if it makes sense)?

@mkevins mkevins self-assigned this May 1, 2019
@hypest
Copy link
Contributor

hypest commented May 3, 2019

Moving to next milestone.

@hypest hypest modified the milestones: v1.3, v1.5 May 3, 2019
@mkevins
Copy link
Contributor

mkevins commented May 7, 2019

After inline paste, the caret position should be "incremented" by the length of the inserted text. This is set explicitly during the paste handling via the forceSelectionUpdate method. A safety check was added to the render method to prevent an out of bounds exception that can occur when the caret is moved to a position that is larger than the text buffer, which may happen as a result of Aztec trimming spaces in the content.
For the purpose of checking this condition, the willTrimSpaces method was introduced, which tries to evaluate whether Aztec will trim spaces, and if so, prevents setting the caret position. The regex that looks for outer spaces (that will be trimmed) also matches on any spaces adjacent to html tags (including inner tags). The result is that whenever the html contains inner tags adjacent to spaces (e.g. a bold word), the caret will not be in the correct position after paste.

@marecar3
Copy link
Contributor Author

marecar3 commented May 7, 2019

Hey @koke,
sorry for not being clear here, I have updated the description based on @mkevins explanation.

If something else needs to be changed, please let me know. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants