Please report any other irregularities here.
>>> My Info: Win7_64, Nightly 48, 32bit, ID 20160409030219 STR_1: 1. Open attachment 8721034 [details] 2. Click between "r" and "o" in string "background-image", type "x" 3. Click between "a" and "d" in string "box-shadow", type "y" 4. Press Ctrl+Z 5. Press Ctrl+Z 6. Type "asdf", then press Left/Right. Press Ctrl+A AR: After Step 5 letter "x" disappears and caret teleports between "r" and "o" in "background-image" In Step 6 caret doesn't move. "fdsa" appears after caret. Ctrl+A doesn't work ER: Either X or Y X) In Step 5 nothing should happen Y) In Step 6 text should be edited in a normal way Note: In case somebody's going to argue with _me_ again: Current behavior is completely unacceptable, and even if somebody thinks that restoring text in non-focused elements if cool idea (it's not) then it's clearly not working good. (Y) is just wrong, believe me.
When doing undo, should we move focus by step 5?
Priority: -- → P3
It's unclear. At least current spec, HTMLEditor cannot clear undo stack at changing focus. I think that we should follow Chromium's behavior if it's possible because of the compatibility of document.execCommand("undo").
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #2) > It's unclear. At least current spec, HTMLEditor cannot clear undo stack at > changing focus. I think that we should follow Chromium's behavior if it's > possible because of the compatibility of document.execCommand("undo"). Chrome seems to move focus by step 5.
Chromium moves focus at undoing/redoing a transaction. So, I think that you're right. On the other hand, Edge behaves odd. An undo removes both characters and moving focus, and a redo inserts both characters at each position and moving focus to the latter editor.
Another concern is, what happens when you edit in 3 editors and 2nd editor is removed from DOM tree or made non-editable before undoing.
https://jsfiddle.net/d_toybox/4qtov2v9/ Oh, Chromium just does nothing when undoing/redoing something isn't available but the index of the stack is modified. For example, type "a" at the editor0, "b" at the editor1, "c" at the editor2, then, click "Toggle editable" or "Attach or detach to/from the tree". Then, Ctrl+Z removes "c", then, Ctrl+Z does nothing, finally, Ctrl+Z removes "a". Redo does same thing. On the other hand, before doing redo, same "Toggle editable" or "Attach or detach to/from the tree" is clicked again (i.e., recover the original state), then, redoing "b" causes duplicating "b". I think that this behavior does make sense.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.