[whatwg] DOM Range: redefining behavior under DOM mutation
bzbarsky at MIT.EDU
Thu Apr 7 15:03:45 PDT 2011
On 3/30/11 10:50 AM, Aryeh Gregor wrote:
> That would result in
> but actually, the result in Gecko is
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
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.
More information about the whatwg