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

Sometimes caret does not move to new paragraph on enter #10484

Closed
ellatrix opened this issue Oct 10, 2018 · 2 comments
Closed

Sometimes caret does not move to new paragraph on enter #10484

ellatrix opened this issue Oct 10, 2018 · 2 comments
Assignees
Labels
[Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Bug An existing feature does not function as intended

Comments

@ellatrix
Copy link
Member

Describe the bug

This is an issue after #10439, reported by @aduth: #10439 (review)

To Reproduce
Steps to reproduce the behavior:

  1. New post
  2. Click writing prompt
  3. Cmd+B to bold
  4. Type something
  5. Press Enter
  6. Press Backspace
  7. Press Enter

Expected: Typing in second paragraph.
Actual: Second paragraph created, but caret remains in first.

Works as expected in 3.9.0.
Should have E2E case (could extend "should merge into inline boundary position")

@ellatrix
Copy link
Member Author

The problem as far as I know comes from not being able to pass new instances of strings, so the string value is the same when compared in component did update, where the caret position is retired on merge. Visually it still seems to be restored correctly, but after the inline boundary position if there is formatting. If enter is then pressed, the caret does not moved. I have not figured out yet why that happens.

In any case, this bug only happens sometimes when pressing enter from the outside of a boundary position.

@ellatrix ellatrix added this to the 4.0 milestone Oct 11, 2018
@ellatrix ellatrix added the [Type] Bug An existing feature does not function as intended label Oct 12, 2018
@gziolo gziolo modified the milestones: 4.0, 4.2 - API freeze Oct 16, 2018
@ellatrix ellatrix self-assigned this Oct 18, 2018
@youknowriad youknowriad modified the milestones: 4.2, WordPress 5.0 Oct 27, 2018
@mtias mtias added the [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later label Oct 29, 2018
@youknowriad
Copy link
Contributor

closed by #11287

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

4 participants