On Mon, Nov 7, 2011 at 8:03 PM, Ryosuke Niwa <rn...@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 <jo...@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 <rn...@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.