Contenteditable div中的文件输入在FireFox上不起作用 [英] File input inside contenteditable div not working on FireFox

问题描述

我有一个内容可编辑的div.在该div内，有一个输入文件.但是，此输入文件无法浏览文件.当我从div中删除contenteditable的属性时，输入文件可以浏览文件.怎么了?

I have a contenteditable div. Inside this div, there is an input file. However, this input file can't browse a file. When I delete the attribute of the contenteditable from the div, the input file is able to browse file. What's wrong?

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

versus

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

推荐答案

我可以确认此行为(当前不在可以在CanIUse处了解可发布的内容)以获取Firefox.

I can confirm this behavior (currently not on the know-issues over at CanIUse for contenteditable) for firefox.

contenteditable 上的whatwg规范指出:

The whatwg spec on contenteditable states:

contenteditable内容属性是枚举属性其关键字是:
空字符串，true和false.
空字符串和true关键字映射为 true状态.
false关键字映射为 false状态.
此外，还有第三个状态，即继承状态，即缺少默认值(以及

The contenteditable content attribute is an enumerated attribute whose keywords are:
the empty string, true, and false.
The empty string and the true keyword map to the true state.
The false keyword maps to the false state.
In addition, there is a third state, the inherit state, which is the missing value default (and the invalid value default).

真实状态表示该元素是可编辑的. 继承状态表示该元素的父元素是可编辑的. false状态表示该元素不可编辑.

The true state indicates that the element is editable. The inherit state indicates that the element is editable if its parent is. The false state indicates that the element is not editable.

内容可编辑"上的 MDN条目状态:

The MDN entry on 'Content Editable' states:

在HTML5中，任何元素都是可编辑的.

In HTML5 any element can be editable.

，但稍后再继续:

几乎可以在所有HTML元素中使用它.

It can be used in almost all HTML elements.

还没有指定可以(不)使用哪些元素.

yet, doesn't specify what elements it can (not) be used on.

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

These are my test-results for FireFox (noting that this doesn't appear to be a recent regression, FF12 behaves the same way):

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(对我来说似乎是矛盾的).

Note test 3 (a contradiction), 8 (although that's probably not what you want..) and 11 (which appears as a contradiction to me).

现在，我期望正在发生的事情，
是Firefox开发人员阅读 Dungeons& Dragons 拖曳放置模型的安全性部分6.7.9:

Now, what I expect that is happening,
is that firefox-developers read Dungeons & Dragons Drag & Drop model's security section 6.7.9:

请考虑一个提供某些内容的敌对页面，并让用户选择该内容并将其拖放(或实际上是复制和粘贴)到受害者页面的contenteditable区域.如果浏览器不能确保仅拖动安全内容，则选择中的潜在不安全内容(例如脚本和事件处理程序)一旦拖放(或粘贴)到受害站点中，即可获得受害站点的特权. 因此，这将导致跨站点脚本攻击.

Consider a hostile page providing some content and getting the user to select and drag and drop (or indeed, copy and paste) that content to a victim page's contenteditable region. If the browser does not ensure that only safe content is dragged, potentially unsafe content such as scripts and event handlers in the selection, once dropped (or pasted) into the victim site, get the privileges of the victim site. This would thus enable a cross-site scripting attack.

并采取了进一步措施(试图保护用户).
您与D&D有什么关系?很好..从正在运行的测试代码片段中选择01 [____][Browse] WORKS并将其拖放(并拖放)到(^所在的位置):09 [____][Browse] DOES NO^T WORK ...(并且可以看到工作输入的副本也没有"工作).

and took that one step further (in trying to protect the user).
How is D&D related you ask? well.. select 01 [____][Browse] WORKS from the running test-snippet and drag (& drop) it into (where the ^ is): 09 [____][Browse] DOES NO^T WORK... (and see that the copy of the working input also doesn't work).

但是，这并不能解释测试3或8或...(而且我猜至少测试3是个错误)，实际上.我了解一些继承，但这似乎不一致.

However, that doesn't explain test 3, or 8 or... (and I'm guessing at least test 3 is a bug), in fact.. I'm still scratching my head here; I understand some inheritance but this appears inconsistent.

我希望看到有人在这里发布更好的答案(我将其发布为答案，因为显然可以发表很多评论，但也不认为这是确定的答案...)

I'd Love to see someone post a better answer here (I posted this as as answer as it is clearly to much for a comment, but don't feel this is a definitive answer either...)

我在测试中添加了一个按钮，该按钮将测试7的父div的contenteditable设置为false.单击该按钮可使测试7正常工作.

I've added a button to the test that sets contenteditable to false for the parent div of test 7. Clicking it makes test 7 work.

实际上，这可能是一个解决方案(取决于您的工作).
看来，这种行为强制执行了所见即所得的模型"(可选的带有原始源选项卡/区域)和实际的所呈现事物(预览").
就像邮件撰写器中的三个选项卡(例如)一样:所见即所得，来源，预览...
这意味着您可以拥有一个虚拟"选项卡，该选项卡在被激活后，除了将WYSIWYG编辑器区域的contenteditable切换为false以外，不执行任何其他操作. 如果需要的话(到目前为止，我还没有测试)，可以考虑将所见即所得区域的实时innerHTML复制到预览区域. 因此，看来解决方案是采用此模型来支持Firefox.

That, actually, could be a solution (depending on what you are doing).
It appears that this behavior kind of enforces a 'model' of live WYSIWYG (optionally with raw source tab/area) AND and the actual live rendered thing ('preview').
Just like the three tabs in a mail-composer (for example): WYSIWYG, source, preview...
That means you could have a 'dummy' tab that, when activated, does nothing more than switch the contenteditable of the WYSIWYG editor area to false.
If need be (I didn't test so far) one could consider to copy the live innerHTML of the WYSIWYG area to a preview-area..
Thus, it appears that the solution is to adopt this model to support firefox..

这篇关于Contenteditable div中的文件输入在FireFox上不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！