[whatwg] Automatic transaction should support changing the value of input/textarea

On Tue, Nov 8, 2011 at 4:48 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> Yup, that seems like the right solution. But we should specify exactly
> what the UA should store. I.e. should it store the whole before/after
> values? What should it do if the after-value doesn't match the current
> value when the transaction is reverted?

Changes to CharacterData all internally go through the "replace data"
algorithm in DOM4:

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-cd-replace

I've been told this is more or less how Gecko works internally, too.
It's not so obvious what conditions to check for, though.  I wrote a
test:

data:text/html,<!doctype html>
<div contenteditable>abc</div>
<input type=button value=insert onclick='
var sel = window.getSelection();
sel.focusNode.replaceData(Math.min(sel.focusOffset, sel.anchorOffset),
Math.abs(sel.focusOffset - sel.anchorOffset), "x")
'>

Type "d" at the end, click button, undo: abcd -> abcdx -> abcx
Type "d" at the end, select "d", click button, undo: abcd -> abcx -> abc
Type "d" at the end, select "cd", click button, undo: abcd -> abx -> abx
Type "d" at the end, move cursor before "b", click button, undo: abcd
-> axbcd -> axbd
Select "b", type "d", click button, undo: adc -> adxc -> abxc
Select "b", type "d", move cursor before "d", click button, undo: adc
-> axdc -> abdc

Gecko and WebKit agree in all of these cases.  It suggests that to
undo the replaceData, they just do a reverse replaceData with the same
offset/count, without any sanity check on the contents of the text
node.  In the first four cases, the thing being undone is an insertion
of one character at offset 3, so they just delete the character at
offset 3 if any.  In the last two, the thing being undone is changing
character 1 from "b" to "d", so they just change character 1 back to
"b" regardless of what it is.  This is simple and workable, although
of course a bit weird if the contents have actually changed.

Received on Tuesday, 8 November 2011 06:33:59 UTC