contenteditable div 中的文件输入在 FireFox 上不起作用

Question

我有一个内容可编辑的 div。在这个 div 里面，有一个输入文件。但是，此输入文件无法浏览文件。当我从 div 中删除 contenteditable 的属性时，输入文件能够浏览文件。怎么了？

<div contenteditable="true">
    <input type="file"/>
</div>

versus

<div>
    <input type="file"/>
</div>

Answer 1

我可以确认 firefox 的这种行为（目前不在know-issues over at CanIUse for contenteditable）。

contenteditable 上的 whatwg 规范指出：

contenteditable 内容属性是一个enumerated attribute，其关键字是：
空字符串、true和false。
空字符串和true 关键字映射到真实状态。
false 关键字映射到 false 状态。
此外，还有第三种状态，继承状态，即missing value default（和invalid value default）。

true 状态表示元素是可编辑的。 继承状态表示如果它的父元素是可编辑的。 false 状态表示该元素不可编辑。

MDN entry on 'Content Editable' 声明：

在 HTML5 中，任何元素都可以编辑。

但稍后会继续：

几乎可以在所有的 HTML 元素中使用。

但是，没有指定它可以（不）用于哪些元素。

这些是我对 FireFox 的测试结果（注意这似乎不是最近的回归，FF12 的行为方式相同）：

01 <input type="file" />                            WORKS              <br>
02 <input type="file" contenteditable="true" />     DOES NOT WORK      <br> 
03 <input type="file" contenteditable="" />         WORKS (wtf?)       <br>
04 <input type="file" contenteditable="false" />    WORKS              <br>
05 <input type="file" contenteditable="foobar" />   WORKS              <br>

<div>
  06 <input type="file" />                          WORKS
</div>

<div contenteditable="true">
  07 <input type="file" />                          DOES NOT WORK
</div>

<div contenteditable="true">
  <div contenteditable="false">
    08 <input type="file" />                        WORKS
  </div>
</div>

<div contenteditable="true">
  09 <input type="file" contenteditable="true" />   DOES NOT WORK
</div>

<div contenteditable="true">
  10 <input type="file" contenteditable="" />       DOES NOT WORK
</div>

<div contenteditable="true">
  11 <input type="file" contenteditable="false" />  DOES NOT WORK
</div>

<div contenteditable="true">
  12 <input type="file" contenteditable="foobar" /> DOES NOT WORK
</div>

<button onclick="
  document.getElementsByTagName('div')[1].setAttribute('contenteditable','false');
">set parent div for 07 to contenteditable="false" to make it WORK</button>

注意测试 3（矛盾）、8（虽然这可能不是您想要的......）和 11（这在我看来是矛盾的）。

现在，我预计正在发生的事情，
火狐开发者是否阅读了 Dungeons & Dragons Drag & Drop model 的安全部分 6.7.9：

考虑一个提供一些内容的恶意页面，并让用户选择并将该内容拖放（或者实际上是复制和粘贴）到受害者页面的contenteditable 区域。如果浏览器不能确保只拖动安全的内容，选择中的脚本和事件处理程序等可能不安全的内容，一旦拖放（或粘贴）到受害站点，就可以获得受害站点的权限。 这将因此导致跨站点脚本攻击。

并更进一步（试图保护用户）。
你问 D&D 有什么关系？好吧.. 从正在运行的 test-sn-p 中选择 01 [____][Browse] WORKS 并将其拖放到（^ 所在的位置）：09 [____][Browse] DOES NO^T WORK... （并看到工作输入的副本也没有不工作）。

但是，这并不能解释测试 3、8 或……（我猜至少测试 3 是一个错误），事实上……我仍然在这里摸不着头脑；我了解一些继承，但这似乎不一致。

我很乐意看到有人在这里发布更好的答案（我将其发布为答案，因为它显然很适合发表评论，但也不认为这是一个明确的答案...)

编辑：
我在测试中添加了一个按钮，将测试 7 的父 div 的 contenteditable 设置为 false。单击它可以使测试 7 工作。

实际上，这可能是一个解决方案（取决于您在做什么）。
这种行为似乎强制实施了实时 WYSIWYG 的“模型”（可选择使用原始源选项卡/区域）和实际的实时渲染事物（“预览”）。
就像邮件编写器中的三个选项卡（例如）：所见即所得、源代码、预览...
这意味着您可以拥有一个“虚拟”选项卡，当它被激活时，只会将 WYSIWYG 编辑器区域的 contenteditable 切换为 false。
如果需要（到目前为止我没有测试），可以考虑将 WYSIWYG 区域的实时 innerHTML 复制到预览区域..
因此，看来解决方案是采用这种模式来支持firefox..