You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you write text into the quill editor, undoing / redoing the changes works unreliable when called from the context menu or the browser-menu. Tested in FF 44.0.2, Opera 35.0, Chromium 48.0, InternetExplorer 11.
Steps to reproduce:
1.) Clean Quill editor on demo page (not strictly necessary, just easier to see the result)
2.) Enter some text, best with a couple of line breaks
3.) Undo the last insert with keyboard shortcut (!) (i.e. CTRL+Z)
4.) Undo the second-to-last insert with context-menu (right mouse button) or from the application menu (often in menu "Edit")
Expected behaviour:
The undo from the browser should undo the second-to-last insert
Actual result:
The undo from the browser has no effect. The next undo from the browser sometimes works, depending on the browser: in FF it doesn't seem to work, other browser are handling this better.
If you switch between the two methods (keyboard shortcut and browser-menu-based undo) the result is very varying. Sometimes a few lines get undone (or redone) but not necessarily in the correct order, sometimes a redo from using the keyboard shortcut remains and previous changes get undone. Many line breaks remain in the editor when using the undo from the browser. Play around with undo / redo by shortcut and then note how the browser-undo/-redo does some weird stuff (a little dependant on the browser, but all I've tested are doing it "wrong")
Using CTRL+Z only works as expected in all cases I have tested so far.
I believe this is an issue affecting all rich text editors utilizing contenteditable. If you do anything special, which most editors do, the native undo manager gets confused. There are some proposals to add an API so rich text editors can tell the browser what to do but this is currently not available as a web standard. The workaround is to disable the native undo/stack so it at least does not do the wrong thing. This is probably be how Quill will have to address the problem as well.
Quill 2.0 has been released (announcement post) with many changes and fixes. If this is still an issue please create a new issue after reviewing our updated Contributing guide 🙏
If you write text into the quill editor, undoing / redoing the changes works unreliable when called from the context menu or the browser-menu. Tested in FF 44.0.2, Opera 35.0, Chromium 48.0, InternetExplorer 11.
Steps to reproduce:
1.) Clean Quill editor on demo page (not strictly necessary, just easier to see the result)
2.) Enter some text, best with a couple of line breaks
3.) Undo the last insert with keyboard shortcut (!) (i.e. CTRL+Z)
4.) Undo the second-to-last insert with context-menu (right mouse button) or from the application menu (often in menu "Edit")
Expected behaviour:
The undo from the browser should undo the second-to-last insert
Actual result:
The undo from the browser has no effect. The next undo from the browser sometimes works, depending on the browser: in FF it doesn't seem to work, other browser are handling this better.
If you switch between the two methods (keyboard shortcut and browser-menu-based undo) the result is very varying. Sometimes a few lines get undone (or redone) but not necessarily in the correct order, sometimes a redo from using the keyboard shortcut remains and previous changes get undone. Many line breaks remain in the editor when using the undo from the browser. Play around with undo / redo by shortcut and then note how the browser-undo/-redo does some weird stuff (a little dependant on the browser, but all I've tested are doing it "wrong")
Using CTRL+Z only works as expected in all cases I have tested so far.
Note: this does not happen on a "normal" contenteditable, see https://jsfiddle.net/jd3rgr0g/2/
Possibly related issue: #413
Possibly not related issues (even though they have to do with undo): #15 , #229 , #231
The text was updated successfully, but these errors were encountered: