[whatwg] Feedback on UndoManager spec

Tue Nov 8 06:12:32 PST 2011

On Mon, Nov 7, 2011 at 8:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> * "The author must not be forced to deal with manually handling DOM
>> state just because they want to handle non-DOM state."
>
> I disagree with this requirement. This should be an opt-in feature, not
> something forced upon authors.

I think we agree, then.  My point is that authors should still be able
to use automatic transactions even if they want undo/redo to affect
non-DOM state too, e.g., canvas.  Authors should only be forced to use
manual transactions if they actually don't want the browser to
maintain DOM state.  So allowing unapply/reapply on manual
transactions would resolve this issue.

> Calling unapply/reapply methods for automatic transaction seem like a good
> non-controvertial change. Will make the change in the next iteration.

Okay, great.

>> Okay, thanks.  This is the key point I was missing.  Just so I
>> understand, what's supposed to happen here:
>>
>> 1. Some changes get made in an automatic transaction.
>> 2. Some changes get made in no transaction at all, just a script
>> calling DOM methods.
>> 3. execCommand("undo")
>
> It depends. If the DOM changes made in step 2 does not mutates the highest
> node affecting the automatic transaction in step 1, then step 3 succeeds and
> UA undoes every DOM change made in step 1.
> If the DOM changes made in step 2 mutates the highest node affecting the
> automatic transaction in step 1, then UAs still does its best to unapply the
> transaction but doesn't need to guarantee the states are restored
> completely.

>From my two simple tests, it looks like this is how WebKit behaves,
more or less, but not Gecko or Opera.

> We can't. That's why I have spec'ed the way it is. Keeping the entire DOM
> state is extremely expensive.

Okay.  Then I wonder what it is Gecko is doing, though.

> Yeah, it'll be nice if we could define the behavior precisely but then
> again, there's nothing that prevents authors from modifying DOM in any
> arbitrary way.

Right, but at least then it will either work in all browsers or break
in all browsers.

> This is very expensive to implement, and I'll be opposed to implementing
> such a behavior at least in WebKit.

Okay.

On Mon, Nov 7, 2011 at 11:27 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> Yes, we don't want to track all changes ever made, that is indeed expensive.

What does Gecko actually do, roughly?  In my second test from before,
it looks like undo undoes a change to an unrelated part of the DOM,
which suggests Gecko is actually tracking all changes to the DOM:

data:text/html,<!doctype html>
<div contenteditable>Foo</div>
<script>
var div = document.querySelector("div");
getSelection().selectAllChildren(div);
document.execCommand("bold");
document.body.appendChild(document.createTextNode("bar"));
document.execCommand("undo");
</script>

"bar" doesn't appear anywhere in the DOM in Firefox 9.0a2.  How does
that happen, if it's not tracking all DOM changes to undo them?  What
changes does it not track?

> What we should do is to define exactly how the tracking works, and
> what exact operations the browser does to revert a automatic
> transaction.
>
> That way it doesn't matter (from a consistency point of view) what
> changes the page does outside of transactions. All browsers will react
> the same to the "unknown" state of the DOM.
>
> For example, if we say that for each node removed when a automatic
> transaction is created, the browser records that nodes old parent and
> previous sibling. Then we can say that when the automatic transaction
> is undone, the browser checks that the old previous sibling is still a
> child of the parent (unless the previous sibling was null), if the
> test passes, the browser inserts the removed node after the previous
> sibling in the parent.
>
> We could also remember both the following and previous sibling in
> order to be more resilient against unrecorded mutations.
>
> There's lots of options here. The point is we should define the exact
> algorithm that the browser should use.

I'm in favor of any solution that produces consistent results across
browsers.  I think it's a bad idea to leave it unspecified.

On Mon, Nov 7, 2011 at 11:54 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> It'll be nice if we could specify that precisely. From what Anne told me
> today, all DOM operations are defined in terms
> of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-insert
> and http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-remove
> so we can probably define what should happen when unapplying/reapplying
> either one.

There are also attribute changes, and changes to CharacterData data,
and changes to JS expando attributes.