Editor shortcuts break undo

[remi]

Open editor, type Ctrl+B (or click the icon in the toolbar), it auto-inserts **bolded text**. Type Ctrl+Z, it doesn't do anything (expected result: it should remove the auto-inserted text). The same applies to all shortcuts, as far as I can see.

I know that formatting is special (ah! what isn't...), but if something puts text that I can see in the editor window, I expect undo to work on it. If I paste text, I can undo. So the same should go for formatting stuff.

Oh, and it actually goes further than that (and this second bit is a much more annoying bug, I think): edit the post title, then insert a tag (e.g. bold) in the post itself, then Ctrl+Z. This undoes changes to... the title! Even though the focus is not at all into the title line, and new content has been added to the post area, so this is totally unexpected.

(Opera 42 Windows, in case that matters)

[Zecc]

No repro on Firefox and Chrome on Windows 7.

And why should it repro? The undo stack is implemented by the browser, not the forum software.

Go shout at the people who make Opera.

[RaceProUK]

Repro, Chrome 56.numbers on Windows 10.

If I had to guess, script-induced changes don't go onto the undo stack, whereas keyboard input does. I'm guessing this is an issue with the way browsers manage the undo stack rather than the forum software being at fault: IIRC, it was the same on Discourse.

[remi]

@RaceProUK said in Editor shortcuts break undo:

If I had to guess, script-induced changes don't go onto the undo stack, whereas keyboard input does. I'm guessing this is an issue with the way browsers manage the undo stack rather than the forum software being at fault: IIRC, it was the same on Discourse.

That is also what I would say, but I don't know anything about how browsers or works, so that might be totally wrong.

[Zecc]

I think it starts with contenteditable being an underspecced mess; then browsers having different quirky implementations; then not even ideal, bug-free software — let alone real software — having a fair chance at providing a reliable experience.

In other words... business as usual.

Edit: ok, so the composer is actually a textarea and there's no contenteditable in sight. I'm still saying "the browser did it".

[RaceProUK]

@Zecc said in Editor shortcuts break undo:

I think it starts with contenteditable being an underspecced mess

Ah, just like everything else in HTML and CSS then.

[Zecc]

Hmm, seems like it's being worked on, so there's still a glimmer of hope.

Commit Activity · w3c/editing

Specs and explainers maintained by the editing task force - Commit Activity · w3c/editing

(INB4 "but it's being worked on by the W3C")

[RaceProUK]

@Zecc said in Editor shortcuts break undo:

Hmm, seems like it's being worked on

Eh...

If they are working on it, it doesn't look like they're working very hard.

[loopback0]

@RaceProUK Editors like QuillJS manage to get it undo to work properly with their buttons. No idea what magic happens behind the scenes but it works.

[anotherusername]

@Zecc said in Editor shortcuts break undo:

I think it starts with contenteditable being an underspecced mess; then browsers having different quirky implementations; then not even ideal, bug-free software — let alone real software — having a fair chance at providing a reliable experience.

In other words... business as usual.

The editor doesn't use a contenteditable element. It's a regular textarea. But if it did, it'd have totally reinvent undo/redo, because contenteditable elements don't give you that built-in.

[Tsaukpaetra]

I noticed this happen in Excel when I run a macro. Certain actions a macro can take (usually involving data manipulation) clear the undo buffer when run.

Makes for a big sad when you for forgot to save and running the wrong macro destroys a workbook...