This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/forms.html Multipage: https://html.spec.whatwg.org/multipage/#input-type-change Complete: https://html.spec.whatwg.org/#input-type-change Referrer: https://html.spec.whatwg.org/multipage/ Comment: I don't see where the value is set to empty string when changing type to "file" Posted from: 98.110.194.132 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:37.0) Gecko/20100101 Firefox/37.0
The spec has: When an input element's type attribute changes state, the user agent must run the following steps: and then 5 steps. Consider the case of changing from type="text" to type="file". 1) Step 1 does nothing, because the new state does not put the input in the "default" or "default/on" mode. 2) Step 2 does nothing, because the old state put the input in the "value" mode. 3) Step 3 doesn't change the value. 4) Step 4 is only used by things in the Radio Button state so doesn't change the value. 5) Step 5 is to run the value sanitization algorithm, but the File Upload state doesn't define such an algorithm, as far as I can tell. So it seems like the value should just stay whatever it used to be. That's clearly not what UAs actually do; they set value to empty string in this case.
Per some mailing list discussion, it sounds like the answer is "it isn't". So the spec requires the value to be kept around while in the file state, but simply doesn't use it there. Switching _out_ of the file state clears the value back to the default value. This is an odd setup. UAs can clearly optimize it, if they can prove that there is nothing in this spec or other specs that exposes this hidden-but-still-there value, but I think it would be cleaner to just drop the value on entering the file state, so there's no chance of someone starting to use it by accident.
Notes on current browser behavior: <input type="text" value="A"> input.value = "B" input.type = "file" // this is a no-op in Safari 8.0.8 input.type = "text" alert(input.value) // Firefox: A , Chrome: B , IE11/Edge: <empty string> alert(input.getAttribute("value")) // Chrome/Firefox/IE11/Edge: A -------- <input type="text" value="A"> input.value = "B" input.type = "file" // Optionally, choose a file. The test results don't differ. input.type = "checkbox" alert(input.value) // Firefox: A , Chrome: B , IE11/Edge: <empty string> alert(input.getAttribute("value")) // Firefox: A , Chrome: B , IE11/Edge: <empty string>
The Firefox behavior is what the spec has right now. My proposed change doesn't change this behavior, in black-box terms. It just makes it clearer while reading the spec what the behavior is....
https://github.com/whatwg/html/pull/148
For posterity: Filed https://code.google.com/p/chromium/issues/detail?id=532403 and https://connect.microsoft.com/IE/feedback/details/1804117 regarding the tangential compatibility bugs from comment #3.