- From: <bugzilla@jessica.w3.org>
- Date: Tue, 26 Jun 2012 19:11:05 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 --- Comment #6 from Max Lohrmann <post@wickenrode.com> 2012-06-26 19:11:08 UTC --- Well the <input type="file" name="something" /> element has always been readonly (you can't change value) for security purposes. That makes sense as a string could always be manipulated by JS. The File object on the other hand should be "safe" in that - Only the browser can create one on user request (ie. by file input or drag and drop) - JS cannot change it in any way So it should not be a security issue to allow assignment to a file input. For example: <input type="file" name="something[]" onchange="splitFiles();" id="in1" multiple="multiple" /> function splitFiles() { var in = document.getElementById('in1'); //create single inputs for(var i=0;i<in.files.length;i++) { var newEl = document.createElement('input'); newEl.name = "something[]"; newEl.id = '...'; newEl.type = "file"; newEl.value = in.files[i]; // <-- assignment of file object document.appendChild(newEl); //add for upload //create some UI to remove this input //... } //remove the multi-input in.parent.removeChild(in); } This code would split a multi-file-input back to multiple single-file inputs (that way applications with a legacy backend that only supports the classical way could also support multi-file-inputs). Another use would be with File objects obtained by drag and drop. Right now those require XHR to upload, allowing to make them a selection of a file input could simplify some situations as well as provide richer UI (when showing a traditional file input together with a drop area those could stay in sync). -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 26 June 2012 19:18:55 UTC