Block-type changes can affect adjacent sibling block #86
Comments
I should also add… Killer work on this project, team. I have been exploring contentEditable-n-React solutions for a few weeks now. This project is a huge leap forward. Thanks for sharing it! |
Thanks @gscottolson! I think the problem here is that the
One option would be to change I'm thinking the first option might be a little cleaner, though it means that there would be no state distinction between selecting an entire line of text and selection the text plus the newline. Given that we pretty much ignore the newline as content, though, that might be fine. What do you think? |
I think the first solution seems reasonable. Thanks for the quick reply.
Edit: You are right about Notes. |
Looks like Notes does have this problem. :) |
Resolves facebookarchive#86. In cases where the user triple-clicks on a block, then toggles the block type, it feels weird to have the trailing block also change block type. The `SelectionState` resulting from the triple-click is correct, but to improve the interaction here, let's discard the trailing block for this modifier. Test Plan: View rich.html, add three lines of text. - Triple-click first line, toggle H1. Verify that only the first line toggles. - Repeat with second line, verify that only the second line toggles. - Repeat with third line (no trailing block), verify that only the third line toggles. Also select across multiple blocks by dragging, verify that toggling block types properly affects all visibly selected blocks.
Excellent. Thanks for the quick fix! 🎩 |
Repro:
Expected:
Actual:
As I typed this bug with Github Markdown editor, I noticed it also demonstrates this behavior (triple-clicking a line and applying bold will drop the trailing
**
at the beginning of the next line). Maybe this is out of the hands of Draft. However, I do believe that fixing the issue would lead to more reasonable UX.The text was updated successfully, but these errors were encountered: