bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

ASSIGNED
Assigned to

Status

()

Core
Editor
P3
normal
ASSIGNED
2 years ago
a year ago

People

(Reporter: arni2033, Assigned: masayuki)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
>>>   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.
(Reporter)

Updated

2 years ago
No longer blocks: 1277113
(Reporter)

Updated

2 years ago
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
Depends on: 1345690
Depends on: 1345763
You need to log in before you can comment on or make changes to this bug.