Вход в файл внутри contenteditable div не работает на FireFox

Question

У меня есть контент-доступный div. Внутри этого div есть входной файл. Однако этот входной файл не может просматривать файл. Когда я удаляю атрибут contenteditable из div, входной файл может просматривать файл. Что не так?

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

 
versus 
 

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

Answer 1

Я могу подтвердить это поведение (в настоящее время не на know-issues over at CanIUse for contenteditable) для светлячок.

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 «s Раздел безопасности 6.7.9:

Рассмотрим враждебную страницу обеспечения некоторый контент и заставить пользователя выбирать и перетаскивать (или даже копировать и вставлять) этот контент в область contenteditable страницы жертвы. Если браузер не гарантирует, что перетаскивается только безопасный контент, потенциально небезопасный контент, такой как скрипты и обработчики событий при выборе, после его удаления (или вставки) на сайт жертвы получает привилегии места жертвы. Таким образом, это позволит атаковать сценарии межсайтового сценария.

и сделал еще один шаг (пытаясь защитить пользователя).
Как D & D связанный вы спросите? хорошо ... выберите 01 [____][Browse] WORKS из прогона теста и перетащите его (&) в (где ^ есть): 09 [____][Browse] DOES NO^T WORK ... (и убедитесь, что копия рабочего ввода также не работает).

Однако это не объясняет тест 3, или 8 или ... (и я предполагаю, что, по крайней мере, тест 3 является ошибкой), на самом деле .. Я все еще царапаю голову здесь; Я понимаю некоторое наследование, но это кажется непоследовательным.

Мне очень хотелось бы, чтобы кто-то опубликовал лучший ответ здесь (Я отправил это как ответ, поскольку это явно для комментария, но не чувствуйте, что это окончательный ответ либо ...)

EDIT:
Я добавил кнопку на тест, который устанавливает contenteditable ложь для родительского DIV теста 7. После нажатия на кнопку тест 7 работ.

Это, на самом деле, может быть решением (в зависимости от того, что вы делаете).
Похоже, что этот тип поведения навязывает «модель» живого WYSIWYG (опционально с вкладкой/областью исходного источника) И и реальную живую визуализированную вещь («предварительный просмотр»).
Так же, как три вкладки в почтовом композиторе (например): WYSIWYG, источник, предварительный просмотр ...
Это означает, что у вас может быть «фиктивная» вкладка, которая при активации не делает ничего более, чем переключает контент, область редактора WYSIWYG - false.
Если необходимо (я не тестировал до сих пор), можно было бы скопировать живой внутренний HTTML области WYSIWYG в область предварительного просмотра.
Таким образом, похоже, что решение состоит в том, чтобы принять эту модель для поддержки firefox ..