[whatwg] DOM Range: redefining behavior under DOM mutation

[Boris Zbarsky]

On 3/30/11 10:50 AM, Aryeh Gregor wrote:
> That would result in
>
>    <p><b>Foo</b><b>bar</b></p>
>
> but actually, the result in Gecko is
>
>    <p><b>Foobar</b></p>

So I looked into this.  It looks like Gecko does move the text node 
containing "bar" to be a child of the <b> and tracks which selection 
ranges are in the node it's removing so it can reset them when the node 
is inserted.

For those who care, the relevant class is nsRangeUpdater, in 
editor/libeditor/base/nsSelectionState.h in the Gecko tree, and the 
relevant comment is:

   // editor selection gravity routines.  Note that we can't always
   // depend on DOM Range gravity to do what we want to the "real"
   // selection.  For instance, if you move a node, that corresponds to
   // deleting it and reinserting it.  DOM Range gravity will promote
   // the selection out of the node on deletion, which is not what you
   // want if you know you are reinserting it.

The editor notifies nsRangeUpdater about things like "I'm about to move 
a node" and "I'm done moving a node" so that nsRangeUpdater can track 
the fact that that the remove and insert it's seeing are part of a move 
and not unrelated operations.

> So browsers must be special-casing how execCommand() affects
> selections somehow

That's certainly what Gecko is doing, yes.

-Boris