Open Bug 1327826 Opened 8 years ago Updated 2 years ago

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

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

People

(Reporter: arni2033, Unassigned)

References

Details

Attachments

(1 file)

Shows that Ctrl+Z event is not received by onkeydown
(deleted), text/html
Details
>>> 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.
No longer blocks: 1277113
Component: Untriaged → Editor
Product: Firefox → Core
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

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

Assignee: masayuki → nobody
Status: ASSIGNED → NEW
Severity: normal → S3

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.

Attachment #9314176 - Attachment mime type: application/octet-stream → text/html

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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: