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关键字映射到 true状态   false关键字映射到 false状态   此外，还有第三个状态，继承状态，即missing value default（以及invalid value default）。

true state 表示该元素是可编辑的。 继承状态表示如果元素的父元素是可编辑的。 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（这似乎与我相矛盾）。

现在，我期待正在发生的事情，
是firefox开发者阅读 ~~Dungeons＆amp;龙~~ Drag & Drop model的安全部分6.7.9：

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

并采取了更进一步的措施（试图保护用户）你问D＆amp; D有什么关系？好吧..从正在运行的测试代码段中选择01 [____][Browse] WORKS并拖动（＆amp; drop）到^所在的位置：09 [____][Browse] DOES NO^T WORK ...（并查看该副本工作输入也不起作用。）

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

我很想看到有人在这里发布更好的答案（我发布这个作为答案，因为很明显很多评论，但不要觉得这是一个明确的答案...）

修改
我在测试中添加了一个按钮，为测试7的父div设置了contenteditable为false。单击它使测试7工作。

实际上，这可能是一个解决方案（取决于你在做什么）看起来这种行为强制实现所有WYSIWYG（可选择带有原始源选项卡/区域）AND和实际的实时渲染事物（'预览'）的“模型”。
就像邮件编写器中的三个选项卡一样（例如）：WYSIWYG，source，preview ...
这意味着您可以拥有一个“虚拟”选项卡，在激活时，除了将所见即所得编辑器区域的满意度切换为false之外，其他任何内容都不会发生。如果需要（我到目前为止没有测试），可以考虑将WYSIWYG区域的实时innerHTML复制到预览区域。
因此，似乎解决方案是采用这个模型来支持firefox ..

在contenteditable div中的文件输入不适用于FireFox

1 个答案: