590363 - Input element created in JavaScript loses its assigned value when the type is changed to 'hidden'

Status: RESOLVED FIXED

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

Description

[Rudd Zwolinski]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4) Gecko/20100818 Firefox/4.0b4

In Firefox 4, if you create an input element in JavaScript, and give it a value, then give it a type of 'hidden', the value will change to the empty string.

Reproducible: Always

Steps to Reproduce:
1. var in = document.createElement('input');
2. in.name = 'myname';
3. in.value = 'myval';
4. in.value // => 'myval'
5. in.type = 'hidden';
6. in.value // => ''
Actual Results:  
The value of the created input element was an empty string.

Expected Results:  
The value of the created input element is the assigned value.

Workaround: assign the 'type' attribute before you assign the 'value' attribute.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase showing what seems to be happening

Comment 2

[Boris Zbarsky [:bzbarsky]]

Our current behavior is what the HTML5 spec calls for as far as I can see.  In particular, setting .value on a _text_ input (as here) sets the value but not the attribute named "value".  Changing the type doesn't change anything about this situation... but for hidden inputs getting the "value" property gets the string currently in the "value" attribute, which is not set.

We used to do some weirdness here with setting the "value" attribute when changing the type; it looks like Opera and Webkit still do that.

Given the likely web compat implications, requesting blocking; this might need a spec change to spec the weird behavior....

Comment 3

[Mounir Lamouri (:mounir)]

I talked to Hixie and he told me this was taken into consideration when he wrotes the change and he thinks the specifications shouldn't change/revert. For him, this shouldn't break the web and one of the reasons is IE didn't let the author change the type of an input.

IMO, I'm not sure it will be clear to everyone that:
 var input = document.createElement('input');
 input.type = 'hidden';
 input.value = 'foo';
and:
 var input = document.createElement('input');
 input.value = 'foo';
 input.type = 'hidden';
are not the same thing.

Maybe we could wait and see how bad this change is for the web?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> one of the reasons is IE didn't let the author change the type of an input.

At all?  Even if you'd just created it with createElement?  So you can't create non-text inputs in IE?

Comment 5

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

IIRC IE allows the type to be changed once for elements created with createElement.

Comment 6

[Boris Zbarsky [:bzbarsky]]

And in IE, setting .value changes the value attr even for text inputs, right?  So in fact the testcase in this bug used to be interoperable in all browsers?

Comment 7

[Rudd Zwolinski]

These are the results of Boris' test case for all browsers I've tested:
IE 6 - 8:
Value: myval
'value' attr: myval
Value after type change: myval
Value attr after type change: myval

Firefox 2.0 - 3.6, Safari, Chrome:
Value: myval
'value' attr: null
Value after type change: myval
Value attr after type change: myval

Firefox 4.0:
Value: myval
'value' attr: null
Value after type change: null
Value attr after type change: null

To be honest, I had not realized that setting .value and setting the value attr were different things. That is, I didn't realize that every browser wasn't doing what IE is doing. It appears that by changing the type and triggering the "weirdness" we ended up with some code that isn't supposed to work but does in all major browsers.

I would imagine most of the web would not break, but changing the type of an input once from text to something else, which in my opinion would be the default use case of changing the type, definitely works in IE. I guarantee there are *some* sites out there that will break.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I think this needs to block a beta....

Comment 9

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

This is a regression from 3.6, right? Making this block betaN as I suspect we'll revert to something closer to what we used to do, which shouldn't be too risky, right?

Let me know if you think it should get more testing than that.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yes, definitely regression since 3.6.

BetaN should be ok, I think.

Reverting back might be risky, because we don't want to (for now, pending spec changes) actually revert to the behavior we used to have....

Comment 11

[Boris Zbarsky [:bzbarsky]]

I just talked to hixie about this.  He's planning to change the spec to something closer to what we used to do (which itself was similar to what webkit does).

Comment 12

[Hixie (not reading bugmail)]

Spec: http://www.whatwg.org/specs/web-apps/current-work/complete.html#input-type-change
Diff: http://html5.org/tools/web-apps-tracker?from=5375&to=5376

Comment 13

[Mounir Lamouri (:mounir)]

Attachment: Patch v1

There is still one case where the value is going to be reset to the empty string even with the specification change:
var e = document.createElement('input');
e.type = 'text';
e.value = 'foo';
e.type = 'file';
e.type = 'text;
-> e.value == ""

In one hand, I don't think this is going to break anything. In another hand, it feels weird that we are net resetting the value except for type='file'.

I'm not going to ask a specification change but I wanted to point this.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I think that's the desired behavior.

Comment 16

[Mounir Lamouri (:mounir)]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/7a5fed78b780

Thank you for your report Rudd :)