Javascript 将所选内容设置为节点的边缘会使WebKit报告的范围不一致

假设以下DOM树：

<div id="edit" contenteditable="true">
  this content <a id="link" href="http://www.google.com/">contains</a> a link
</div>

正如预期的那样，它的

commonAncestorContainer

是id为

edit

的元素：

console.log(r.commonAncestorContainer);  /* => <div id="edit" contenteditable="true">…</div> */

现在查询当前选择范围的窗口，并检查其

commonAncestorContainer

：

var r2 = s.getRangeAt(0);
console.log(r2.commonAncestorContainer);

你会发现，在Firefox中，结果与预期一致；id为

edit

的同一元素

但是，在WebKit浏览器中，选择范围容器突然变成了锚内的文本节点<代码>“包含”，但当您开始键入时，您会发现您确实不在锚内。WTF

这种行为背后有什么潜在的理由吗？有没有理由认为它不是WebKit bug

---

感谢您的.02美元。

WebKit只允许DOM中的某些位置用作选择边界或插入符号位置。因此，它会修改使用选择的

addRange（）

方法选择的范围，以符合此要求。另见

另一个问题是WebKit在链接末尾有一个特殊的插入符号位置，它将键入的文本放在链接后面而不是链接内部。不可否认，这有点令人讨厌，因为浏览器将选择报告为在链接内。但是，其他内联元素不会发生这种情况，因为您可以在这个修改版的演示中看到：

---

ohh那么你是说该属性返回的元素不正确，你将要编辑的元素不正确？我是说WebKit返回的范围与我们刚才分配给它的范围、Firefox的行为以及浏览器对用户的行为不一致。我明白你的意思了，我在这里查阅了范围文档：，我想您可能发现了一个需要报告的bug。@ars265:这不是bug。@TimDown，不是吗？如果范围对象最初包含节点，为什么它不保留继承的端点，或者文档中描述了这一点：

人们认为在范围内的内容包括所有包含的节点，如果开始节点和结束节点是文本节点或注释节点，则可能会加上它们的一些内容。

并且因为开始节点和结束节点不是文本节点，所以它们会被删除吗？

var s = window.getSelection();
s.removeAllRanges();
s.addRange(r);

var r2 = s.getRangeAt(0);
console.log(r2.commonAncestorContainer);