W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

[whatwg] Exceptions in UndoManager

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Wed, 30 May 2012 00:03:32 -0700
Message-ID: <CABNRm6260abXD37upW3W7LLiteKQP+7iJCW5abCJ6ngQiOACKg@mail.gmail.com>
To: whatwg@whatwg.org
Cc: Olli Pettay <Olli.Pettay@helsinki.fi>, Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Alex Vincent <ajvincent@gmail.com>, Ehsan Akhgari <ehsan@mozilla.com>
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

On Sat, May 26, 2012 at 8:01 PM, Alex Vincent <ajvincent@gmail.com> wrote:
>
> * The spec is inconsistent in a few places.  For instance, in the green
> non-normative section, clearUndo states:
> Removes entries in the undo transaction
> history<http://rniwa.com/editing/undomanager.html#undo-transaction-history
> >before
> position<
> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>and
> resets
> position<
> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>to
> 0.
>
> However, in the normative part, it states:
> The clearUndo() method must remove all entries in the undo transaction
> history <
> http://rniwa.com/editing/undomanager.html#undo-transaction-history>after
> the undo
> position <http://rniwa.com/editing/undomanager.html#undo-position>.
>
> Note that one of these states "before", and the other states "after".  This
> contradiction is not implementable.
>
> * The spec mentions a "DOM transaction
> group<http://rniwa.com/editing/undomanager.html#dom-transaction-group>",
> but does not define that.
>
> * When adding a transaction to a DOMTransaction[] as part of execute's
> merge being true, do we add it to the beginning or the end of the list?
> This matters for .item().
>
> * Exception handling is woefully undefined in this spec:
> ** If my transaction throws an exception during UndoManager.execute(), how
> should that be handled? What happens to transaction groups that were
> previously undone?
> ** If my transaction throws an exception during .undo(), how should that be
> handled?
> ** Ditto redo.
>
> * What precisely lives at UndoManager.item(0)?  The most recently completed
> transaction, or the oldest?
>
> * When UndoManager.execute() is called with an object not implementing
> .undo, or .redo, should we fire some kind of warning to the user?  What
> should happen when we try to undo that transaction?
>
> Given all the above, I think I need to write some tests for UndoManager.
> Anyone mind Jasmine-based tests?
>
> --
> "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 07:04:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT