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
