Bugzilla – Bug 19946
Range fixup for normalize() needs to account for boundary points in removed nodes' parents
Last modified: 2012-11-24 17:38:16 UTC
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=804784
var range = document.createRange();
document.body.textContent = range.startContainer
+ " " + range.startOffset;
Expected is "[object Text] 3". WebKit gets it right. Gecko/Opera say "[object HTMLBodyElement] 1", and IE says "[object HTMLBodyElement] 0" (?!). The spec current requires Gecko/Opera behavior, but that's a bug. Gecko is changing to WebKit's behavior. In the while loop in the algorithm, the range fixup is only
For each range whose start node is current node, add length to its start offset and set its start node to node.
For each range whose end node is current node, add length to its end offset and set its end node to node.
If we're already going to fix up ranges, we may as well do it right -- we should also change boundary points at (current node's parent, current node's index) to (node, length). Otherwise we fix only points in the actual text node, not in in its parent adjacent to it.
Are we sure that doesn't fuck with the cursor position in editing in the wrong way? I should know more about this I suppose, but I don't, but I do know why we introduced some specific Range-handling in the past.
(The specific Range-handling was not necessarily for normalize() by the way, but I suppose it might be similarly affected.)
I don't understand what you mean. What does normalize() have to do with editing? This will improve its effect on cursor position, not harm it.
You have to help me out here. I got
For each range whose start node is /node/'s parent and start offset is /node/'s index, set its start node to /node/ and its start offset to /length/.
For each range whose end node is /node/'s parent and end offset is /node/'s index, set its end node to /node/ and its end offset to /length/.
but I suspect that might be missing some cases.
I think that's right if you change /node/ to /current node/, as I have in comment #0 -- otherwise you're trying to move points that are *before* /node/, which isn't being removed anyway. You want to move points that are after /node/, i.e., before /current node/. Why do you think it's missing cases?
The normalize() algorithm now looks correct to me. Thanks.
Thanks for confirming Mats, nice to run into you again :-)
It seems Range-mutations.html doesn't actually cover normalize() yet, boo. No tests to update.