This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=804784 Test-case: data:text/html,<!doctype html> abcdef <script> document.body.firstChild.splitText(3); var range = document.createRange(); range.setStart(document.body, 1); document.normalize(); document.body.textContent = range.startContainer + " " + range.startOffset; </script> 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. """ http://dom.spec.whatwg.org/#dom-node-normalize 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?
https://github.com/whatwg/dom/commit/58d339113554d72ae2996839afb323ec242f6ddb
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.