[whatwg] UndoManager: restoring selection after undoing deletion

[Alex Russell]

On Thu, Oct 20, 2011 at 12:16 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Hi,
> The way selection is restored on WebKit after undoing selection is different
> from the way it is done on Firefox and Internet Explorer.
> Say you had "hello world" and "world" is deleted by an user. When the user
> undoes the deletion, WebKit selects "world" whereas Firefox and Internet
> Explorer do not select "world". WebKit's behavior matches Mac's NSTextView
> and we probably would like to keep the current behavior.
> However, there's no easy way for the user agent to figure out whether a
> given transaction wants to select some contents on undo or not. In fact, we
> don't even know whether we want to restore selection at all. If an automatic
> transaction was modifying non-text nodes (e.g. SVG line elements), then
> restoring selection isn't desirable at all.
> I can think of two approaches to solve this problem:
>
> Let automatic transactions also have unapply/reapply and call them after
> user agents had done its work, and make the user agent do nothing in regards
> to selection. We can name them afterUnapply/afterReapply if we want. The
> benefit of this approach is that it's very general and authors can do other
> things as well while the disadvantage being author needs to be fully aware
> of platform-convention of how selection is restore upon undo/redo.

There are a couple of competing interests here:

  1.) simple content editable scenarios that don't involve a lot of
code should "just work" the way the underlying OS does
  2.) code-driven editing should be completely normalized by default
  3.) sophisticated code-driven editing will want to re-create
OS-native behavior

It seems like mixing #1 with #2 is what's causing the tension here. It
almost feels like if you add any custom commands, you need to replace
*all* of the default commands. Mix/match feels like the bug here. I
don't like the implications of that in terms of apparent code-size,
but I'm wondering how bad it really is.

> Add a boolean restoreSelection and isDeletion properties to the Transaction
> interface. The user agent restores the selection when the value is true and
> does not restore selection when the value is false. isDeletion is true when
> the transaction is meant to delete contents and false otherwise. (Maybe
> negate the property so that common case will be easy?) The user agents can
> probably use some heuristics to determine whether a given transaction is
> deleting contents or not.
>
> But I don't like either solution so I'm open to your ideas and thoughts on
> this.
> Best,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>
>