Undoing inline marks doesn't work as expected
See original GitHub issueDo you want to request a feature or report a bug?
Feel free to close this report if it’s a duplicate – I searched “undo” but nothing seemed to quite fit. I am not currently developing with Slate.js but discovered a reproducible bug in the example editor.
What’s the current behavior?
Tested in Chrome 58 on Mac
- Visit http://slatejs.org/#/rich-text
- On the top paragraph of the editor, select “ch text, mu”
- Hit delete.
- Hit
cmd-z
.
Current behavior: The re-done text is “mu ch”
What’s the expected behavior?
The editor should restore text to the original state: “ch text, mu”
Issue Analytics
- State:
- Created 6 years ago
- Comments:9 (7 by maintainers)
Top Results From Across the Web
Why is this inline-block element pushed downward?
Its that why " inline-block " element is pushed downward. ... Without overflow:hidden it works as excepted and defined by 2 and 3....
Read more >When a Line Doesn't Break | CSS-Tricks
The inline-block element adds a breaking character at the end of the text. Then the content property space comes after the breaking character ......
Read more >Allow No file preview - neither overlay nor inline
I just discovered that we have no option for disabling the inline previewer. The preview version does not allow for animation in a...
Read more >Fix program errors and improve code - Visual Studio (Windows)
Click on any line of code, right-click to open the context menu, and select Quick Actions and refactorings. If refactoring or improvement ...
Read more >How to Remove an Anchor in Microsoft Word - Alphr
1. Create a new or open a Word document. 2. Go to File (top left corner). 3. At the bottom of the page,...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Some of the selection bugginess seemed to maybe share the same cause, so I was trying to determine if there’s a centralized ticket or effort for that cause, but it doesn’t sound like there’s a single underlying issue. Just learned, for example, about trackpad dragging having a 300ms timeout enforced at the OS level for Mac, which botches quick select/backspace maneuvers.
I’ll probably revisit this once we get through our initial implementation.
In Transforms.removeMarkAtRange,
adding the following logic seems to solve the problem: