html5 - File input inside contenteditable div not working on FireFox -

html5 - File input inside contenteditable div not working on FireFox -

i have contenteditable div. within div, there input file. however, input file can't browse file. when delete attribute of contenteditable div, input file able browse file. what's wrong?

class="snippet-code-html lang-html prettyprint-override"><div contenteditable="true"> <input type="file"/> </div> versus <div> <input type="file"/> </div>

i can confirm behavior (currently not on know-issues on @ caniuse contenteditable) firefox.

the whatwg spec on contenteditable states:

the contenteditable content attribute enumerated attribute keywords are: empty string, true, , false. empty string , true keyword map true state. false keyword maps false state. in addition, there 3rd state, inherit state, missing value default (and invalid value default).

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

the mdn entry on 'content editable' states:

in html5 element can editable.

but continues later-on:

it can used in html elements.

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

these test-results firefox (noting doesn't appear recent regression, ff12 behaves same way):

class="snippet-code-html lang-html prettyprint-override">01 <input type="file" /> works <br> 02 <input type="file" contenteditable="true" /> 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" /> 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" /> not work </div> <div contenteditable="true"> 10 <input type="file" contenteditable="" /> not work </div> <div contenteditable="true"> 11 <input type="file" contenteditable="false" /> not work </div> <div contenteditable="true"> 12 <input type="file" contenteditable="foobar" /> not work </div> <button onclick=" document.getelementsbytagname('div')[1].setattribute('contenteditable','false'); ">set parent div 07 contenteditable="false" create work</button>

note test 3 (a contradiction), 8 (although that's not want..) , 11 (which appears contradiction me).

now, expect happening, firefox-developers read dungeons & dragons drag & drop model's security section 6.7.9:

consider hostile page providing content , getting user select , drag , drop (or indeed, re-create , paste) content victim page's contenteditable region. if browser not ensure safe content dragged, potentially unsafe content such scripts , event handlers in selection, 1 time dropped (or pasted) victim site, privileges of victim site. this enable cross-site scripting attack.

and took 1 step farther (in trying protect user). how d&d related ask? well.. select 01 [____][browse] works running test-snippet , drag (& drop) (where ^ is): 09 [____][browse] no^t work... (and see re-create of working input doesn't work).

however, doesn't explain test 3, or 8 or... (and i'm guessing @ to the lowest degree test 3 bug), in fact.. i'm still scratching head here; understand inheritance appears inconsistent.

i'd love see post improve reply here (i posted as reply much comment, don't sense definitive reply either...)

edit: i've added button test sets contenteditable false parent div of test 7. clicking makes test 7 work.

that, actually, solution (depending on doing). appears behavior kind of enforces 'model' of live wysiwyg (optionally raw source tab/area) , and actual live rendered thing ('preview'). 3 tabs in mail-composer (for example): wysiwyg, source, preview... means have 'dummy' tab that, when activated, nil more switch contenteditable of wysiwyg editor area false. if need (i didn't test far) 1 consider re-create live innerhtml of wysiwyg area preview-area.. thus, appears solution adopt model back upwards firefox..

html5 file input