如何在不同浏览器中可靠获取选区内容的首个元素节点

本文详解 `clonecontents().firstelementchild` 在 firefox 与 webkit（chrome/safari）中行为不一致的根本原因，并提供跨浏览器兼容的解决方案，包括使用 `commonancestorcontainer` 等替代策略及实用代码示例。

在基于 contenteditable 的富文本编辑场景中，开发者常通过 window.getSelection() 获取用户选区，再调用 range.cloneContents() 提取选中内容的文档片段（DocumentFragment），进而尝试用 firstElementChild 定位最外层 HTML 元素。然而，该方式在 Firefox 中可能返回 节点，而在 Chrome 或 Safari 中却返回 null——这并非 Bug，而是由浏览器对 cloneContents() 返回片段结构的实现差异所致。

? 根本原因：cloneContents() 的片段结构不一致

Range.cloneContents() 创建的是一个无上下文的文档片段，其内部结构取决于选区边界是否精确落在元素边界上：

• 若用户全选 test（即从 开始、到 结束），Firefox 常将 作为片段的直接子节点，故 firstElementChild 可正常返回；
• 但在 WebKit 中，即使看似“全选”，实际选区起点/终点可能落在文本节点内部（如 "test" 的中间字符）。此时 cloneContents() 会复制出纯文本节点或嵌套更深的结构，导致片段根下无 子节点，firstElementChild 自然为 null。

例如：选中 "es"（"test" 中间两个字母），cloneContents() 在 WebKit 中仅生成包含 "es" 的 Text 节点，无任何元素子节点。

✅ 推荐方案：使用 commonAncestorContainer + 向上遍历

更健壮的做法是不依赖 cloneContents() 的结构，而转向选区本身的语义信息：

function getSelectedElement() {
    const selection = window.getSelection();
    if (!selection || selection.rangeCount === 0) return null;

    const range = selection.getRangeAt(0);

    // commonAncestorContainer 是选区内所有节点的最近公共祖先节点（可能是 Text 或 Element）
    let ancestor = range.commonAncestorContainer;

    // 若是文本节点，向上查找其父元素；否则直接使用（已是 Element）
    if (ancestor.nodeType === Node.TEXT_NODE && ancestor.parentNode) {
        ancestor = ancestor.parentNode;
    }

    // 可选：进一步过滤，确保是 contenteditable 区域内的有意义元素（如 strong, em, span 等）
    if (ancestor && ancestor.nodeType === Node.ELEMENT_NODE) {
        return ancestor;
    }

    return null;
}

function test() {
    const el = getSelectedElement();
    console.log('Selected outermost element:', el); // 如 , , 或 
}

✅ 优势：commonAncestorContainer 是标准 API，所有现代浏览器行为一致；它反映选区的逻辑归属，而非克隆后可能失真的 DOM 结构。