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

Oops, Gmail's new look is confusing me.  I did Reply instead of Reply
to all.  Resending.  Ryosuke, you replied off-list, so you should
probably repeat the reply on-list.

On Tue, Nov 8, 2011 at 11:39 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> The value of input and textarea elements isn't CharacterData. The default
> value of textarea maybe stored as CharacterData but not the value.

Sorry, I was confusing this with the other thread or something.  But
it would make sense for the same algorithm to apply.  E.g., if the
user made a change to some text in an input and then a script changed
it and then the user tried to undo, the result should be the same as
if the same sequence of actions occurred in a contenteditable text
node.  Test:

data:text/html,<!doctype html>
<input value=abc>
<input type=button value=insert onclick='
var input = document.querySelector("input");
input.value = input.value.substring(0, input.selectionStart)
+ "x"
+ input.value.substring(input.selectionEnd);
'>

Running the same manual tests as before in WebKit:

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

WebKit behaves exactly the same for CharacterData nodes and inputs, it
looks like.  Gecko seems to not undo user changes if there were any
script changes to the value -- in all six of those tests, undo does
nothing, unlike in WebKit.

On Tue, Nov 8, 2011 at 11:47 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Hm... so the only way this could happen is if script assigned a value to the
> value IDL attribute, so it's probably safe to say we should abort (i.e. no
> restoration of the value)

Do you think that's how modifying contenteditable text nodes should
behave too?  Also, doesn't this require that you store the old value
with every change?  The way WebKit seems to do it now for both inputs
and text nodes is to just dumbly reverse the operation without
checking if it makes sense, which means you only need to store offset,
removed text, and length of added text.

Received on Tuesday, 8 November 2011 11:06:27 UTC