本文解析 `clonecontents().firstelementchild` 在 firefox 与 webkit（chrome/safari）中行为不一致的根本原因，并提供跨浏览器兼容的替代方案，确保能稳定获取用户选中文本所在的实际 dom 元素。
在处理 contenteditable 区域的文本选区时，开发者常通过 window.getSelection() 获取选区范围，再调用 range.cloneContents() 创建文档片段（DocumentFragment），进而尝试用 firstElementChild 提取首个子元素。然而，该方法在 Firefox 中可能返回 <strong> 节点，而在 Chrome 或 Safari 中却返回 null——这并非 Bug，而是由各浏览器对 cloneContents() 的实现差异导致的。
关键原因在于：cloneContents() 仅克隆选区范围内“完全包含”的节点；若选区跨越文本节点边界（如只选中 "test" 中的 "es"），则 <strong> 元素本身未被完整选中，其内容被拆解为纯文本节点，导致克隆后的 DocumentFragment 根下无任何元素节点，firstElementChild 自然为 null。
Firefox 在某些场景下对部分选中元素的处理更宽松，而 WebKit 严格遵循规范，仅保留完整包含的元素。
✅ 推荐解决方案：使用 range.commonAncestorContainer 结合层级遍历
commonAncestorContainer 返回选区所有节点的最近公共祖先（可能是文本节点、元素节点等），而其父节点 parentNode 往往就是包裹选中文本的语义化容器（如 <strong>、<em>、<span> 等）。改进后的健壮写法如下：
function getSelectedElement() {
const selection = window.getSelection();
if (!selection || selection.rangeCount === 0) return null;
const range = selection.getRangeAt(0);
// 获取选区最近公共祖先的父节点（通常是目标包装元素）
let candidate = range.commonAncestorContainer.parentNode;
// 安全防护：避免 parentNode 为 null 或 document
while (candidate && candidate.nodeType !== Node.ELEMENT_NODE) {
candidate = candidate.parentNode;
}
return candidate || null;
}
function test() {
const el = getSelectedElement();
console.log('Selected wrapping element:', el); // 如 <strong>, <p>, 或 null
}⚠️ 注意事项：
- commonAncestorContainer 可能是文本节点（#text），因此必须向上查找最近的元素节点；
- 若用户选中的是纯文本（无任何 HTML 标签包裹），最终将返回 contenteditable 容器自身或其最近块级父元素；
- 不要依赖 cloneContents() 的结构做元素判断——它适用于复制内容，而非语义分析；
- 如需精确判断选区是否“完全位于某元素内”，可结合 range.intersectsNode() 或 range.containsNode() 进行二次验证。
总结：跨浏览器 DOM 选区分析应以 语义位置（commonAncestorContainer + 向上遍历） 为核心逻辑，而非依赖 cloneContents() 的碎片化结构。这一模式既符合规范，又具备高度兼容性，是构建富文本编辑器选区工具链的可靠基础。
