13250 2011-07-14 15:25:07 +0000 In "replace data", bail out early if the data will be the same 2011-07-24 18:04:13 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED INVALID P2 enhancement --- 13164 1 ayg annevk bzbarsky mike www-dom public-webapps-bugzilla oldest_to_newest 51026 0 ayg 2011-07-14 15:25:07 +0000 Before the step "Insert data into data after offset code units.", add something like # Substring data with offset offset and count count, and let current data be the result. # If current data equals data, terminate these steps. That way, if there's no actual change, mutation events won't fire and ranges won't be affected. E.g., if you have a selection in a text node like foo[bar]baz, and you do text.data = text.data, we want the selection to remain foo[bar]baz and not become []foobarbaz. Among browsers I tested a few months ago, Chrome does this special-casing, and it makes sense. That way text.data = text.data is a no-op, which is what you'd expect. Authors are likely to do things like function getNewData(data) { if (flibberty()) { data += "!"; } if (squizzle()) { data = data.replace(/elephant/g, "cantaloupe"); } return data; } text.data = getNewData(text.data); and will naturally expect that nothing will happen if flibberty() and squizzle() are both false. Of course, if they're really worried about range mutations they should be passing the actual text node and using appendData/replaceData to make the changes, but we can at least make it easy for them to get it right in as many cases as possible. 51027 1 bzbarsky 2011-07-14 15:29:58 +0000 This may or may not make sense. Actually doing the check to see whether the data is the same is not exactly cheap, and is a definite performance loss when the data is NOT the same... I can see this going either way, but I think you should look for some implementor feedback here. There may actually be a reason no one but Chrome does this. 51028 2 ayg 2011-07-14 15:39:54 +0000 Well, it's certainly simpler not to do it, and more closely matches browsers. Plus authors can easily emulate the effect if they care, and in almost no cases *will* they care what happens to Ranges. Plus Anne pointed out that for mutation events, we probably do want to give listeners the chance to react even if the new data is the same. So I'm withdrawing this request, and will remove the special case from DOM Range, unless someone wants to keep it.