1327826 - Ctrl+Z undoes operations in non-focused [contenteditable] elements and teleports caret there

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[arni2033]

>>>   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.

Comment 1

[Makoto Kato [:m_kato]]

When doing undo, should we move focus by step 5?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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").

Comment 3

[Makoto Kato [:m_kato]]

(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.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0c831ec4c5dc

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a720dcd0b848c524ce31ecd1683637918fcf0b9b

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Resetting assignee which I don't work on in this several months.

Comment 10

[thierry.excoffier]

Attachment: Shows that Ctrl+Z event is not received by onkeydown

It seems to me that another problem is linked to this one.

On Ctrl+Z on unfocused editables, the undo is done but the onkeydown handler is not triggered.

This is annoying because the container of the editable is not aware of a possible content change.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to thierry.excoffier from comment #10)

On Ctrl+Z on unfocused editables, the undo is done but the onkeydown handler is not triggered.

I don't reproduce the symptom in Nightly for Windows.

This is annoying because the container of the editable is not aware of a possible content change.

Why don't you listen beforeinput whose inputType is "historyUndo"?

And,

First problem: Control+Z with the focus on one DIV will do the undo on the other DIV.

No, all browsers share a single undo manager at least between all contenteditables in same document. contenteditable can be added, removed, etc. Therefore, it does not make sense to create undo managers per editing host.