- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 7 Nov 2011 20:27:32 -0800
On Mon, Nov 7, 2011 at 5:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> 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.
>>
>> Is the resulting DOM just undefined? ?Why isn't it defined to be
>> whatever the state was before the automatic transaction, so any
>> intervening changes just get undone too?
>
> As far as I understand, implementing such a behavior will be extremely
> expensive in WebKit and I don't want to do that.
Yes, we don't want to track all changes ever made, that is indeed expensive.
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.
/ Jonas
/ Jonas
Received on Monday, 7 November 2011 20:27:32 UTC