- From: Alex Vincent <ajvincent@gmail.com>
- Date: Wed, 30 May 2012 08:43:51 -0700
- To: Ryosuke Niwa <rniwa@webkit.org>
- Cc: whatwg@whatwg.org, Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Olli Pettay <Olli.Pettay@helsinki.fi>, Ehsan Akhgari <ehsan@mozilla.com>
1. "What state will the UndoManager be in when an exception happens?" There may be transactions that were undone, cropped off by the transact() call, which per the spec are now unrecoverable. Also, in the undo or redo cases, we might be in the middle of a merged transaction. The spec says we can't call undo while we're unapplying a transaction... nor can we call redo. So where will we be - both during the event dispatch and in the aftermath? 2. "What information about the exception will be included with the event - or with the UndoManager?" 3. "If the UndoManager can recover somehow to a known good state without intervention, how can it indicate that - and possibly, what that good state would look like?" 4. "If no recovery is completed, is it acceptable to mark the UndoManager in an error state and prevent further transactions from either happening or being recorded until both undo and redo stacks have been completely cleared?" (I'm thinking of a fatal error state, which can be recovered if you throw away all your history.) 5. If there is a recovery by one event listener, should another event indicating that recovery be dispatched, so that earlier event listeners are aware of the new good state? I can write up a simple HTML + SVG document illustrating the UndoManager Exception cases I can dream up, if anyone's interested. There's four main areas: during transact with no undone transactions, during undo where we may be in the middle of a transaction group, during redo where we may be in the middle of a transaction group, and during transact where some transactions have been undone. For question 3, I would propose including an UndoManager mockup without methods: a static data representation of the default after-state. Note that it is perfectly okay in my opinion for the UndoManager to report "I cannot recover from this on my own," and not provide this mockup at all. On Wed, May 30, 2012 at 12:03 AM, Ryosuke Niwa <rniwa@webkit.org> wrote: > When an exception is thrown within transact(), the most sane behavior > appears to be rolling back all DOM changes that have made thus far (this in > turn may also fail due to mutation events, etc...). Also this is not > possible with manual transactions because browsers don't keep track of > what's happening in the DOM, etc... > > So how about just firing an event like DOMTransactionException at the undo > scope host to let scripts handle them? > > - Ryosuke > > > -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001
Received on Wednesday, 30 May 2012 15:44:40 UTC