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

[Ryosuke Niwa]

On Wed, Nov 30, 2011 at 6:50 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> I don't think I'm understanding your set of steps.
>
> Let me try to clarify:
>
> 1. input.value is "foo".
> 2. automatic transaction starts.
> 3. input.value is changed to "hi".
> 4. automatic transaction ends.
> 5. input.value is changed to "foo bar".
> 6. input.value is changed to "hi".
> 7. undo is called on undomanager.
>
> at this point I don't see a reason we wouldn't want to change the
> value back to "foo". This doesn't seem like a particularly interesting
> scenario because the change is perfectly undoable since the value
> matches.


The problem is that shadow nodes are lost when we assigned "foo bar". So
unless we store the value when we assign "foo bar", we can't revert the
change.


> 1. input.value is "lot's of text here".
> 2. automatic transaction starts.
> 3. input.value is changed to "lot's of words here".
> 4. automatic transaction ends.
> 5. input.value is changed to "some words here".
> 6. undo is called on undomanager.
>
> Here it seems like there is "no perfect solution" since we don't know
> if the page would want to revert back to "lot's of text here", or keep
> the "some words here". Or maybe change to "some text here" (though
> this obviously isn't a viable solution since it'll too easily break in
> non-trivial scenarios).
>
> If we define that the implementation has to revert the value back to
> "lot's of text here" it means that the implementation must store the
> "delta" as well as either the whole "before value" or the whole "after
> value". Or store both the "before value" and "after value" and no
> delta.


I'm not convinced that storing the "whole" before value is much of an issue
at least for UAs that implement textarea/input using a shadow DOM since we
can just store the pointer to the shadow text nodes. When scripts assigns a
value to the element, we can detach the nodes from the element but still
keep the text nodes around. Of course, text nodes may be modified by the
user but that's okay because any user-initiated modifications to the text
nodes will be done as automatic transactions.
 So in your scenario (+ user editing):

   1. input.value is "hello world".
   2. automatic transaction starts.
   3. input.value is changed to "foo". // We keep reference to #text("hello
   world")
   4. automatic transaction ends.
   5. User types " bar" after "foo". // We keep the reference to #text("foo
   bar") in addition to remembering the delta.
   6. input.value is changed to "goodbye".
   7. Undo is called on undomanager. // Detach #text("foo bar") and attach
   #text("hello world")


By the way, it appears that both Firefox and Opera treat every assignemnt
to input.value as an "automatic transaction" already inside input/textarea.
In addition, they appear to have a separate undo scope inside
textarea/input elements. On the other hand, WebKit and Internet Explorer
appear to clear undo stack in the input/textarea element when the
assignment happens, and they share the same undo scope as the document. So
we need to be extremely careful not to break either behavior.

In the above scenario, steps 5 and 6 create new automatic transactions
inside the shadow for Firefox and Opera. On WebKit and Internet Explorer,
step 5 creates new transaction and step 6 clears it. However on all 4 UAs,
we're overriding this behavior by the undo manager of the document.

- Ryosuke