Bug 19946 - Range fixup for normalize() needs to account for boundary points in removed nodes' parents
Summary: Range fixup for normalize() needs to account for boundary points in removed n...
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-11-12 12:00 UTC by Aryeh Gregor
Modified: 2012-11-24 17:38 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2012-11-12 12:00:45 UTC
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=804784


data:text/html,<!doctype html>
var range = document.createRange();
range.setStart(document.body, 1);
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.
Comment 1 Anne 2012-11-12 12:10:25 UTC
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.
Comment 2 Anne 2012-11-12 12:11:18 UTC
(The specific Range-handling was not necessarily for normalize() by the way, but I suppose it might be similarly affected.)
Comment 3 Aryeh Gregor 2012-11-13 11:33:20 UTC
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.
Comment 4 Anne 2012-11-16 19:38:54 UTC
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.
Comment 5 Aryeh Gregor 2012-11-19 12:20:05 UTC
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?
Comment 7 Mats Palmgren 2012-11-20 12:54:59 UTC
The normalize() algorithm now looks correct to me.  Thanks.
Comment 8 Anne 2012-11-20 12:56:23 UTC
Thanks for confirming Mats, nice to run into you again :-)
Comment 9 Aryeh Gregor 2012-11-24 17:38:16 UTC
It seems Range-mutations.html doesn't actually cover normalize() yet, boo.  No tests to update.