文件输入内部contenteditable div不工作在FireFox

Question

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

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

 
versus 
 

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

Answer 1

我可以证实这种行为（目前未在know-issues over at CanIUse for contenteditable）用于Firefox。

WHATWG的规范上contenteditable状态：

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

真实状态表示该元素是可编辑的。 继承状态指示如果元素的父元素为可编辑元素。 假状态指示元素不可编辑。

的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的开发人员阅读 龙与地下城&龙 Drag & Drop model的安全部分6.7.9：

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

并采取了更进一步的措施（试图保护用户）。
D & D你有什么问题？以及从运行的测试代码片段中选择01 [____][Browse] WORKS，然后将其拖入（&下拉）（^）：09 [____][Browse] DOES NO^T WORK ...（并查看工作输入的副本也不起作用）。但是，这并不能解释测试3，或8或...（我猜测至少测试3是一个错误），事实上，我仍然在这里挠我的脑袋;但是，这并不能解释测试3或8。我了解一些继承，但这看起来不一致。

我喜欢看到有人张贴更好的答案在这里（我张贴这是因为答案，因为它显然是多的评论，但不觉得这是一个明确的答案要么...）

编辑：
我添加了一个按钮，设置CONTENTEDITABLE为false测试7的父DIV点击它使测试工作7测试。

这实际上可能是一个解决方案（取决于你在做什么）。
看起来，这种行为类型强制实时所见即所得（可选地与原始源选项卡/区域）AND和实际呈现的事物（'预览'）的'模型'。
就像邮件编辑器中的三个选项卡（例如）：所见即所得，源代码，预览...
这意味着您可以有一个“虚拟”选项卡，该选项卡在激活时只会切换contenteditable所见即所得编辑器区域为false。
如果需要（我迄今为止没有测试过），可以考虑将所见即所得区域的实时innerHTML复制到预览区域。
因此，似乎解决方案是采用此模型来支持firefox ..