[whatwg] Exceptions in UndoManager

[Alex Vincent]

   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 at 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