Closed Bug 205618 Opened 17 years ago Closed 14 years ago

Changing the value of a hidden field changes the defaultValue too.

Categories

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

x86
All
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: ari.savolainen, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507

When the value of a hidden field (<input type="hidden" name="foo" value="bar"
/>) is changed by javascript (document.forms[0].foo.value = "not_bar") the
defaultValue of that field is changed too.

Reproducible: Always

Steps to Reproduce:
1. Create a page with hidden fields and javascript to change it and to inspect
the value and the defaultValue.
2. Change the value of the hidden field.
3. Inspect the value and the defaultValue.

Actual Results:  
The defaultValue has the same value than the value.

Expected Results:  
The defaultValue should have been the same than the original value.
Keywords: testcase
Attachment #123258 - Attachment description: Testcase → Testcase. Default value should alert "bar"
I can reproduce this bug on
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030512
Browser, not engine ---> DOM Level 0
Assignee: rogerl → dom_bugs
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → ashishbhatt
Confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug is also present on firefox v0.9.
me too.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

See http://web2.mms3.com/~colin/bug.html

Using other types of element (textarea / text) works as expected (i.e.
defaultvalue does not change).

Tested on Microsoft IE6 - defaultValue not changed
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.3?
We're not taking changes for Aviary 1.0.x other than security fixes and
regressions along the Aviary 1.0.x series (i.e., regressions from security fixes).
Flags: blocking-aviary1.0.3? → blocking-aviary1.0.3-
Reproduced in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050508 Firefox/1.0+ (like comment 2, also windows)

OS -> All
OS: Linux → All
Also affected is input type="button" and type="submit".
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 305481 has been marked as a duplicate of this bug. ***
This is intended behaviour per spec:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
I think you may have misinterpreted the spec for defaultValue. 

The text "this represents the HTML value attribute of the element" applies to
"text","file" or "password" 

However it goes on to say without qualifying a particular element type "The value of this attribute does not change if the contents of the corresponding form control, in an interactive user agent, changes."

Please reopen as a bug.
Jonas,

Can you please explain why you think the bug is invalid?

If not, please reopen it.

Thank you,

Garrett

BTW - I could not email you: bugmail@sicking.cc failed.
(In reply to comment #12)
> I think you may have misinterpreted the spec for defaultValue. 
> 
> The text "this represents the HTML value attribute of the element" applies to
> "text","file" or "password" 
Which means that the behaviour is undefined for any other controls, and the browser is free to implement that however it likes. It would therefore not be wise for a script to rely on any particular semantics in this case.

> 
> However it goes on to say without qualifying a particular element type "The
> value of this attribute does not change if the contents of the corresponding
> form control, in an interactive user agent, changes."

From the context, this is clearly this is referring to the visible control on the screen. Since this is type="hidden", there is no such form control, and therefore it obviously cannot change.

> 
> Please reopen as a bug.

Since the standard does not require this behaviour, we need to look at whether the behaviour as implemented makes sense. I think that it makes more sense to implement it for hidden in the same way as for text et. al. makes more sense than special-casing the undocumented case (and if we do special case it, perhaps it should be to make it raise an exception?)
> From the context, this is clearly this is referring to the visible control on
> the screen. Since this is type="hidden", there is no such form control, and
> therefore it obviously cannot change.

It can change - you can get a DOM reference to the hidden input field and change its value in a script.

> Since the standard does not require this behaviour, we need to look at
> whether the behaviour as implemented makes sense.

The behaviour as implemented does not make sense. It makes it difficult to implement page dirty checking where hidden input fields are used to store the state of changes the user has made to the page.

Internet Explorer has chosen to implement this the same way as other input fields: http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/defaultvalue.asp
> The behaviour as implemented does not make sense. It makes it difficult to
> implement page dirty checking where hidden input fields are used to store the
> state of changes the user has made to the page.
> 

Absolutely. 

There is a reason we have defaultValue.

Jonas, in the DOM level 2 doc you linked, here is the def'n for defaultValue:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-36152213

defaultValue of type DOMString, modified in DOM Level 2
    Represents the contents of the element. The value of this attribute does not change if the contents of the corresponding form control, in an interactive user agent, changes.


I guess the confusing point of the definition is that they call defaultValue an attribute, when it's not really, it's a property on the DOM object. e.g. input.defaultValue is not the same as input.getAttribute('defaultValue'). Not a great definitions, but sufficient for purpose of this discussion.


Status: RESOLVED → REOPENED
Resolution: INVALID → ---
The spec says about the 'value' property:

When the type attribute of the element has the value "button", "hidden", "submit", "reset", "image", "checkbox" or "radio", this represents the HTML value attribute of the element.

So when the type is hidden setting the value sets the attribute. The attribute doesn't change if you then change the type to "text". Thus, when you access the 'defaultValue' property of the "text" you will get the changed value that is still in the attribute.


Garett: the link you gave talks about the <textarea> element and does not apply here. You want to look here:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26091157

Note that the spec uses the word "attribute" both to refer to things in the markup, i.e. <input thisisanattribute="myattr"> and to javascript properties, for example .value or .defaultValue.

Yes, this is confusing, so you have to be really careful when reading the spec.

I agree that the spec is not ideal, but it is what it is. If you want to hide formcontrols i suggest that you use CSS instead of changing the type attribute. I.e. set mycontrol.style.display="none".
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → INVALID
(In reply to comment #17)
> The spec says about the 'value' property:
> 
> When the type attribute of the element has the value "button", "hidden",
> "submit", "reset", "image", "checkbox" or "radio", this represents the HTML
> value attribute of the element.
> 
> So when the type is hidden setting the value sets the attribute.

True.

 The attribute
> doesn't change if you then change the type to "text". 

We are not doing that.

Thus, when you access the
> 'defaultValue' property of the "text" you will get the changed value that is
> still in the attribute.
> 

Are you high?

Please find somewhere in the spec that says this: "When the .value property (or attribute) changes the .defaultValue property MUST also be changed."

Regardless of what the spec sais or who is interpreting it:

1. defaultValue in hidden is to me extremely useful for non-trivial form change detection.

2. Supported by Internet explorer and I would argue widely used. People will continue to be blindsided by the fact that it doesen't work in mozilla until its fixed.

3. The current behavior makes no logical sense and violates the whole point of the existance of defaultValue which is to do the very thing that mozilla currently does not do for hidden fields.

4. To some it would be consistant or at least make sense if defaultValue simply was not a member of the hidden element this would be an improvement however given that its a useful feature and one that IE supports -- taking this approach only makes life more difficult for the rest of the world.
> > The spec says about the 'value' property:
> > 
> > When the type attribute of the element has the value "button", "hidden",
> > "submit", "reset", "image", "checkbox" or "radio", this represents the HTML
> > value attribute of the element.
> > 
> > So when the type is hidden setting the value sets the attribute.
> 
> True.
> 
>  The attribute
> > doesn't change if you then change the type to "text". 
> 
> We are not doing that.

We do not change the "value" attribute[*] no. If you do getAttribute("value") before and after setting the type you'll see that it is unchanged.

> Thus, when you access the
> > 'defaultValue' property of the "text" you will get the changed value that is
> > still in the attribute.
> > 
> 
> Are you high?

I did *not* inhale! :)

> Please find somewhere in the spec that says this: "When the .value property 
> (or attribute) changes the .defaultValue property MUST also be changed."

The spec says that for "text" inputs the .defaultValue property:
# When the type attribute of the element has the value "text", "file" or
# "password", this represents the HTML value attribute of the element

I interpret that as meaning that the value attribute and the .defaultValue property always have the same value when the type is "text". And since a previous operation changed the value attribute, the .defaultValue property will logically follow.

You clearly seem to read the spec in a different way, so let me ask you this. Which of the following statements do you think should return something different from what we currently do, given the below markup. I've added in comments what we currently return:

<input type="hidden" id="myinput" value="bar">

myinput.type                    // returns "hidden"
myinput.value;                  // returns "bar"
myinput.getAttribute("value");  // returns "bar"
myinput.value = "foo";
myinput.value;                  // returns "foo"
myinput.getAttribute("value");  // returns "foo"
myinput.type = "text";
myinput.getAttribute("value");  // returns "foo"
myinput.defaultValue;           // returns "foo"


[*]In my comments i'm going to refer to javascript properties (such as .value and .style) as 'properties' and DOM attributes (such as type="text" and bgcolor="green") as 'attributes'. This is not the terms used by the spec, but it tends to reduce confusion.

> The spec says that for "text" inputs the .defaultValue property:
> # When the type attribute of the element has the value "text", "file" or
> # "password", this represents the HTML value attribute of the element
> 


That's the first sentence of the def'n. 

> I interpret that as meaning that the value attribute and the .defaultValue
> property always have the same value when the type is "text".

Here's the second sentence of the def'n:

"The value of this attribute does not change if the contents of the corresponding form control, in an interactive user agent, changes."

Default value does not change.




Yes, that is true when type="text" (or file or passwd). However it doesn't say anything about the behaviour for type="hidden". But by the time the .defaultValue property is read in the testcase the type is text and so the behaviour is defined.

Again, please tell me which of the steps in my example in comment 20 you think is wrong.

I agree that the behaviour is less then optimal, however we are just doing what the spec says here.
Let's break this definition down.


Sentence 1:
"When the type attribute of the element has the value "text", "file" or "password", this represents the HTML value attribute of the element."



Sentence 2:
"The value of this attribute does not change if the contents of the
corresponding form control, in an interactive user agent, changes."


Sentence 1 applies to "text", "file" or "password". I interpret this as: The initial value of the input.

If we see example 2 (attachment 184723 [details]), we can see that my interpretation is applied to text inputs.

Sentence 2 does not make mention of the inputs TYPE attribute. Therefore, sentence 2 applies to ALL inputs.


I don't interpret sentence 2 to apply to type="hidden" inputs. The third sentence:

# When the type attribute of the element has the value "button", "hidden",
# "submit", "reset", "image", "checkbox" or "radio", this represents the HTML
# value attribute of the element

Clearly applies to type="hidden" inputs. This contradics the second sentence.
Sorry, i missed that you were referring to the .defaultValue attribute.

I think it's a very far streach to not let the "When" part of the first sentence doesn't streatch to the second sentence. I agree that it should have been written much clearer.

However, that still would not change the behaviour of the testcase. What happens is that when type=hidden writing to .value writes to the value attribute (per 3rd sentence of the .value property spec). When the type is then changed to text reading the .defaultValue property will read the value attribute (per first sentence of the .defaultValue property spec).

Please please please comment on my example in comment 20 and let me know which step in that process you think is wrong.
Sorry if I can't express myself properly but english is not my mother language and talking about such subtle details require great knowledge of the language and being able to understand all the things properly, please be gentle.

I don't know if the spec says so, but this wouldn't be the first time that some spec was written without taking into account some facts and leaves some grey area that doesn't make sense, so let's imagine that we can rewrite the spec and try to see what is useful:

I wanna check the current value set in the HTML of the input, currently in Mozilla we can check that the input is of type text or password and read .value, if the input is of type hidden both .value and .defaultValue gives the same result, but no one will use .defaultValue as that won't work with Internet Explorer and looking at the code it would look strange to use .defaultValue to get the current value, so everybody uses .value to read the current value of inputs (except radio and checkbox...)

so .defaultValue won't be used to get the data that currently returns according to the spec, so it's "useless"

Now, if I wanna know the value that was originally set in the HTML according to the spec I can do it only for the types text and password, and we are left alone for hidden ones. Most of the web authors won't realise that the operation is failing and so Mozilla users will have to use broken interfaces that will behave almost like if javascript was disabled.

What would happen if this bug is fixed?
I bet that none a single page in all the world relies on the current behavior as I stated previously this behavior won't work with IE and isn't intuitive. On the other side the fact that people has CC themselves and voted for this bug shows that they want a behavior that it is logical and works cross-browsers without having to resort so a really ugly hack like it would be to replace all the <input type="hidden" with <input type="text" style="display:none"

I know that other times when a spec wasn't clear people has asked for the reason of that spec and how should behave in that case taking into account the real state of the web, wouldn't it a good a idea to ask for clarification to someone else?
Heres another reference, the ECMA spec itself.

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
See section 8.6.2.6

This spells out exactly how defaultValue is derived and what happens if an object does not support defaultValue.



(In reply to comment #25)
> Sorry, i missed that you were referring to the .defaultValue attribute.
> 
> I think it's a very far streach to not let the "When" part of the first
> sentence doesn't streatch to the second sentence. I agree that it should have
> been written much clearer.
> 

English is not your native language, is it?

Take a look at the first sentence again, with the following considerations:

 * defaultValue is a property of HTMLInputElement. 
 * a hidden input is an HTMLInputElement. 
 * For "Text", "File" and "Password" inputs, defautValue this represents the HTML value attribute of the element
 

> However, that still would not change the behaviour of the testcase. What
> happens is that when type=hidden writing to .value writes to the value
> attribute (per 3rd sentence of the .value property spec). When the type is then
> changed to text reading the .defaultValue property will read the value
> attribute (per first sentence of the .defaultValue property spec).
> 
> Please please please comment on my example in comment 20 and let me know which
> step in that process you think is wrong.
> 

Jonas, this is not a debate of what should happen to defaultValue when the TYPE attribute is changed. 

this bug depends on bug 158209
> > I think it's a very far streach to not let the "When" part of the first
> > sentence doesn't streatch to the second sentence. I agree that it should 
> > have been written much clearer.
> 
> English is not your native language, is it?

Rudeness is going to get you nothing but my ignoring you.

> Take a look at the first sentence again, with the following considerations:
> 
>  * defaultValue is a property of HTMLInputElement. 
>  * a hidden input is an HTMLInputElement. 
>  * For "Text", "File" and "Password" inputs, defautValue this represents the
> HTML value attribute of the element

Please read the definition of 'value' attribute which has the exact same sentence construction. If the "When" of the first sentence doesn't strech into the second the second and third sentence say the complete opposite things.

> Jonas, this is not a debate of what should happen to defaultValue when the 
> TYPE attribute is changed. 

This bug is about the testcases attached to it, both change the type attribute. If you think there is errorous behaviour even when type doesn't change, please attach a testcase showing that.


I can understand that this is annoying to developers, and if this is indeed a problem that affects many users we will consider deviating from the spec. For developers that want to work around the specced behaviour in the meantime, just use <input type=text style="display:none;"> rather than <input type=hidden>
Depends on: 158209
> This bug is about the testcases attached to it, both change the type attribute.
> If you think there is errorous behaviour even when type doesn't change, please
> attach a testcase showing that.

Um, neither of testcases change the type attribute as far as I can tell.
(In reply to comment #30)
> > This bug is about the testcases attached to it, both change the type attribute.
> > If you think there is errorous behaviour even when type doesn't change, please
> > attach a testcase showing that.
> 
> Um, neither of testcases change the type attribute as far as I can tell.
> 

Yes, your observations are correct.


Jonas, please read the testcases confirm that this is true.
Hmm.. sorry, i don't know where i got that idea. I might have been looking in a different bug.

Anyway, the way I read the spec .defaultValue is very poorly defined for types other than "text", "file" and "password".

It is however specified that for type="hidden" chaning the .value property changes the value attribute, and that for the defined types .defaultValue maps to the value attribute.

If .defaultValue would not change we would have to for hidden fields have some sort of internal value that remembers the value before the attribute is changed. This would be an fairly complicated setup I think, so I'd rather not.

It's very easy to work around as a developer, so the question is if there are any real sites out there that breaks because of this.
> It is however specified that for type="hidden" chaning the .value property
> changes the value attribute, and that for the defined types .defaultValue maps
> to the value attribute.

I can find where that is specified. Can you please provide a reference?

> If .defaultValue would not change we would have to for hidden fields have some
> sort of internal value that remembers the value before the attribute is
> changed. This would be an fairly complicated setup I think, so I'd rather not.

This is probably how defaultValue is already implemented for other input fields.

> It's very easy to work around as a developer, so the question is if there are
> any real sites out there that breaks because of this.

As Peter noted earlier the current behavior makes no logical sense. Yes, it breaks real sites. This broke the product I work on when we added Firefox support because our code made the perfectly reasonable assumption that defaultValue would behave the same for a hidden input field as any other input field.

Can someone with the appropriate permissions please reopen this bug?
(In reply to comment #33)
> > It is however specified that for type="hidden" chaning the .value property
> > changes the value attribute, and that for the defined types .defaultValue 
> > maps to the value attribute.
> 
> I can find where that is specified. Can you please provide a reference?

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485
# When the type attribute of the element has the value "button", "hidden",
# "submit", "reset", "image", "checkbox" or "radio", this represents the HTML
# value attribute of the element

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26091157
# When the type attribute of the element has the value "text", "file" or
# "password", this represents the HTML value attribute of the element

> This is probably how defaultValue is already implemented for other input
> fields.

No it's not. It always maps to the value attribute in the current implementation (except for some whitespace stripping in some cases).
The full specification for the value attribute on an HTMLInputElement:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485
# When the type attribute of the element has the value "text", "file" 
# or "password", this represents the current contents of the corresponding 
# form control, in an interactive user agent. Changing this attribute changes 
# the contents of the form control, but does not change the value of the HTML 
# value attribute of the element. When the type attribute of the element has 
# the value "button", "hidden", "submit", "reset", "image", "checkbox" 
# or "radio", this represents the HTML value attribute of the element. See the 
# value attribute definition in HTML 4.01.

This states what the value attribute for a DOM reference to an HTML input field will return.

The full specification for the defaultValue attribute on an HTMLInputElement:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26091157
# When the type attribute of the element has the value "text", "file" 
# or "password", this represents the HTML value attribute of the element. The 
# value of this attribute does not change if the contents of the corresponding 
# form control, in an interactive user agent, changes. See the value attribute 
# definition in HTML 4.01.

This states what the defaultValue attribute for a DOM reference to an HTML input field of type text, file, or password will return (the value contained in the input field with the page loads). The specification *does not* state what defaultValue will return for a hidden input field (it is undefined).

> It is however specified that for type="hidden" chaning the .value property
> changes the value attribute, and that for the defined types .defaultValue 
> maps to the value attribute.

Now consider if the specification for the defaultValue attribute applied to hidden input fields as well. The defaultValue attribute is mapped to the value contained in the value attribute for the input field *when the page first loaded*. This is what the second sentence in the specification for defaultValue is talking about. You omitted this sentence when you quoted the specification in your previous update.

Given some common sense about how one would expect defaultValue to work for a hidden input field, and the fact that other browsers work as expected can this please be reopened?
Sigh. Ok people. We clearly don't agree on how to interpret the spec. We're clearly not going to convince each other so if anyone's interested in clarification please bring it up with W3C.

However I don't think that's the important part anyway. What's more important here is if we think this affects enough users is important enough that we need adjust to IE behaviour or not.

The way to do that is to point to sites that has been affected by this.
(In reply to comment #36)
> Sigh. Ok people. We clearly don't agree on how to interpret the spec. We're
> clearly not going to convince each other so if anyone's interested in
> clarification please bring it up with W3C.

Have you looked at the javascript reference I posted above? defaultValue is also an internal javascript property that is well defined.  To me both the ECMA and DOM specs govern the behavior.  The reference even goes through psuedocode with all steps one should follow to derive it.

I don't know about you but I don't know many well known web sites with form interfaces that are not used as simple search or message boards and I don't know how to go about finding them as internal code is filtered out of most search engines and its not some obvious display artifact.  So in my view the only realistic feedback is for people with first hand experience to report it.  We've run across this by accident in our software applications sold to thousands throughout the world.  I think the majority of cases you will find this will be with more complex form interfaces of internal web enabled applications and not so much publically accessable Internet sites.

> However I don't think that's the important part anyway. What's more important
> here is if we think this affects enough users is important enough that we need
> adjust to IE behaviour or not.
> The way to do that is to point to sites that has been affected by this.

To me in an open project like this I don't expect anyone else to fix it unless the folks reporting it care enough to submit a reasonable patch.  To me its just classifying this as invalid / resolved that I want changed.  FWIW 9 people have voted for this already -- how many do we need? :)
Right, so it appears we will not be able to rely on the defaultValue attribute on a DOM reference to a hidden HTML input field to report the value one would logically expect it to (given the behaviour of the defaultValue attribute on DOM references to HTML input fields of other types).

Because of this we have had to change remove hidden input fields that keep track of page changes in our commercial web application from:

<INPUT type="hidden" name="foo">

and change them to:

<INPUT style="display: none" name="foo">

in order for us to correctly implement page dirty checking.
You need to log in before you can comment on or make changes to this bug.