Unaccessible history state

Do you want to request a feature or report a bug?

bug

What’s the current behavior?

https://jsfiddle.net/doodlewind/wo348Lc0/

1. Using the <kbd>delete</kbd> button to delete some selected text.
2. Focus on text, press cmd-z.

Previous state can’t be replayed with cmd-z since the editor is again blurred.

Behavior with cmd-z that loses focus:

What’s the expected behavior?

cmd-z shouldn’t blur the editor. Expected Behavior with <kbd>undo</kbd> and <kbd>redo</kbd> button:

Some investigations

This behaviour is regularly encountered in my editor project and it’s frustrating, since user will think their changes are ‘lost’. But in fact the history stack is preserved.

In Slate’s default examples, toolbar buttons doesn’t trigger this issue since changes are fired from onMouseDown and prevented default, editor is still focused afterwards. But when building advanced toolbar with color pickers or table pickers, mouse events can still blur the editor. In this case cmd-z is not usable.

IMHO it makes sense to always focus after redo or undo, the question is the place for the logic. Calling redo().focus() and undo().focus() as a workaround will break history stack and throw errors. Another workaround that calls delete().focus() is also awkward.

[doodlewind]

@chemzqm That’s exactly what #1330 implements.

[isubasti]

@ianstormtaylor it seems that with the newest version of slate, the first operation is set_value which cause the error on undoing when history stack size is equal to 1. I got around this with hasUndo/hasRedo helpers that filters out stack that only have set_selection(focus/blur) or set_value(initialization) operation and handleRedo and handleUndo change function that check if it has undo/redo and run change.redo()/change.undo() till the change is not a set_selection operation.