Open Bug 1523270 Opened 2 years ago Updated 1 year ago

Editable component (textarea) ctrl+z undo history lost after value property assignment


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




Tracking Status
firefox66 --- affected


(Reporter: myf, Unassigned)


Artificial (JavaScript) value change wipes textarea (text input) undo history, so invoking Undo command cannot revert it.

Simple test case in dataURI:

data:text/html,<!doctype html><title>Textarea history persistence test</title><textarea cols="50" rows="20" onblur="this.value+='\n\nValue amended. Now try to restore previous state.'">This is the initial value. Make some changes and then restore initial value using Menu - Edit - Undo (Ctrl+Z).%0A%0AThen press tab or click outside and try again.</textarea>

Expected outcome: Undo reverts both changes made by typing AND by JavaScript value assignment.

Actual outcome: Undo can revert only changes made by typing; JavaScript change sets initial state anew and erases prior history.

Haven't spotted exact version but appeared quite recently; bug is present in current stable branch (64), not present in older non-quantum fork [1]. As far as my memory goes, Firefox always retained history very well and I relied on it in my personal webapps quite blindly, so this is quite nasty regression FMOPW.

[1] (Tried current Basilisk with Gecko/20100101 Goanna/4.1 Firefox/60.9 Basilisk/20181218 , have nothing more at hand ATM.)

This is expected behavior (bug 1386484 and etc). Before landing some bugs, we always stored undo history even if setting value. Some browsers discard undo history by setting value and this causes performance issue (bug 1346723), so we decide that we change this behavior.

Priority: -- → P5

Oh, thanks for quick response. I was afraid it will be something like this. I understand that retaining history is expensive, but this certain optimization breaks UX of pretty much every 'simple JavaScript-aided textarea' in the wild: Wikipedia, Github [1] and even the MDN sample code showing principle of 'Inserting something to textarea' [2] comes into mind as notable examples.

I know performance is important and to be honest I always quite admired how much data could Firefox handle in such invisible detail as value history, but in this case it was too big sacrifice [3].

So is this decision final? If so, it should be mentioned at MDN page as a warning (First affected Firefox version was 57, is it right?), such as "Don't forget to implement own value history management if your script amends elements value", with corresponding code sample ("original ctrl-z restoring shim").

[1] Type word into comment textarea on e.g. Github issue page, select it, press Ctrl+B. Your word is now surrounded with asterisks. To revert it you have to manually delete asterisks on both sides. You have also lost undo history. /Better type them asterisks yourself next time./
[3] And if you want to be on par with "some browsers", keep in mind their history management is often a joke. Maybe performance improving joke, but still UX joke.

This is extremely annoying.
Many websites rely on the undo history not being reset when the contents of a textarea are changed, as mentioned before.
Implementing a custom undo system using javascript is messy and impractical (There appears to be no way to modify the undo buffer, or properly detect undo events (remember, not every OS uses ctrl+z))

This is great remark: I haven't realized there is no such event handler like onundo or onbeforeundo or anything similar what would be prerequisite for reliable way to revert to prior text value.

I was thinking about simplest shim remedying such crippling value assignment and thought it could be possible to, for example, "simply clone" (sic!) the textarea element, save and hide the original instance with history intact, save information about last selection "somewhere", amend the clone and swap to original when need arises (= history buffer of the clone reaches it's beginning, i.e. invoking undo there changes nothing). Like you said, there is no reliable way to know when such need arises, so any attempt to hotfix this in simple and reliable way is doomed in advance. Not only because listening to keyboard events is clearly wrong (as you mentioned), but moreover because undo command can be invoked from textarea context menu or even Main menu Edit submenu, i.e. "uncapturable" for JavaScript in the page.

So again, is it really worth to be broken (but, eh, "fast") the same way like every other current browser?
Should we (web developers) really throw away textarea elements and switch to something like Codemirror the moment we decide to add something like "make bold" / "add signature" button?

It would be nice competitive advantage to have reliable text fields again. I'd really like to show off how I could return back to any state my field had, regardless how was its content formed.

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