266744 - [FIXr]unable to clear the value of an input type="file"

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Richard Gibson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

In-page ECMAScript and ECMAScript in the location bar with the "javascript:"
protocol are unable to alter the value on an input type="file" element (which is
possible through "Evaluate Javascript..." in the DOM Inspector).  Attemping to
do so generates a NS_ERROR_DOM_SECURITY_ERR exception.  This is probably
intentional to avoid malicious uploading of files, but there should be a way to
clear the value to prevent uploading of any file with a given input.

However, the behavior is needed (in my case) because I am trying to script a
multiple file input from independed file inputs, and I use cloneNode when a new
input is needed.  cloneNode correctly copies the value attribute, but since I
cannot clear it I end up with an input ready to upload the same file twice
rather than the new blank input that I desired.

Reproducible: Always
Steps to Reproduce:
1. Open a page with a form containing a file input
2. Attempt to set its value, for example with
"javascript:void(document.getElementById('fileInputId').value='');"
Actual Results:  
Error: uncaught exception: [Exception... "Security error"  code: "1000"
nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location:
"javascript:void(document.getElementById('fileInputId').value=''); Line: 1"]

Expected Results:  
Cleared the value of the input

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

maybe cloneNode on the <input> should clear the value...

Comment 2

[Boris Zbarsky [:bzbarsky]]

No, as comment 0 says cloneNode() is correctly preserving the value.

Perhaps we should allow attempts to set the value to "" to pass the security
check?  There should be no security issue with that, methinks.

Comment 3

[Richard Gibson]

(In reply to comment #2)
> Perhaps we should allow attempts to set the value to "" to pass the security
> check?  There should be no security issue with that, methinks.

That is exactly the behavior I'm hoping for.

Comment 4

[Johnny Stenback (:jst)]

Yeah, sounds reasonable to me.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

a "me too" from me too :)

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 163894 [details] [diff] [review]
Like so

sr=jst

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

+  //check secuity

wanna fix that typo while you're at it? :) and maybe add a space after the //?

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 163894 [details] [diff] [review]
Like so

>-  //check secuity
>-  if (mType == NS_FORM_INPUT_FILE) {
>+  //check secuity.  Note that setting the value to the empty string is always

As long as you're changing this please fix the "secuity" typo.

Looks good to me, too.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 11

[Richard Gibson]

I just double-checked this with Firefox 1.0.6 on Windows 2000, and I think it
resurrected itself because I still get the NS_ERROR_DOM_SECURITY_ERR.  Is
IsEmpty() failing on a JavaScript-provided empty string or something?

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Could you attach a testcase?

Comment 13

[Richard Gibson]

Attachment: testcase

Comment 14

[José Jeria]

If not mistaken, this was never checked in to the 1.0.x branch, see comment 10

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

indeed

Comment 16

[Richard Gibson]

Yeah, that was it.  How embarassing.  I don't really know how to follow the
development branches (or find the code for them); will this be fixed in 1.5?

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes. You can download Deer Park Alpha 2 or a nightly build to test.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

*** Bug 293695 has been marked as a duplicate of this bug. ***