Open Bug 158209 Opened 18 years ago Updated 1 year ago

Reset hidden value don't work

Categories

(Core :: Layout: Form Controls, defect, P3)

x86
Windows 2000
defect

Tracking

()

mozilla1.4alpha

People

(Reporter: topperlu, Assigned: john)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

<html>
<head>
<title>Content</title>
<script language="JavaScript" type="text/javascript">
<!--
function changeIt() {
	var objHidden = document.getElementById("hiddenField");
	objHidden.value = "newValue";
	var objText = document.getElementById("currValue");
	objText.value = objHidden.value;
}

function reportIt() {
	var objHidden = document.getElementById("hiddenField");
	var objText = document.getElementById("currValue");
	objText.value = objHidden.value;
}
//-->
</script>
</head>
<body>

<form name="form1" >
	<input id="hiddenField" type="hidden" value="oldValue">
	<input type="reset" value="Reset">
</form>

<form name="form2" >
	<input id="currValue" type="text" value="oldValue">
	<input type="button" value="Change it" onclick="changeIt();">
	<input type="button" value="CurrentValue" onclick="reportIt();">
</form>

</body>
</html>
<!--
1. press ChangeIt
2. press Reset
3. press CurrentValue
-->
Confirmed on WinXP trunk build 2002071608.

Reporter: next time you file a bug, please use the Bugzilla Helper at
<http://www.mozilla.org/quality/help/bug-form.html>.

I uploaded the testcase to <http://www.q1n.org/mozilla/bugs/bug_158209.html>.
Status: UNCONFIRMED → NEW
Ever confirmed: true
-->
Assignee: rods → jkeiser
Attached file Testcase
This testcase demonstrates what happens to each of the relevant values when you
set .value, .defaultValue and the value attribute.  It is not a pretty sight in
IE; the value attr and .value are the same and .defaultValue is different. 
From here springs our problem.	We don't treat any of them differently.
There are three things we can do here:

(1) deliberately do not fix this bug, saying that since .value == .defaultValue
== value attr, the input is irrevocably changed when you change .value.
(2) change input type=hidden to work like input type=text, making .defaultValue
== value attr and .value be different.  This seems preferable but has an unknown
cost (regressions may turn up).
(3) add in a hack to act just like IE, and store the original value in
defaultValue.  This is highly distasteful.
Priority: -- → P2
Target Milestone: --- → mozilla1.4alpha
Verified on 12/16 Trunk, Win XP
Keywords: testcase
Depends on: 184732
*** Bug 165529 has been marked as a duplicate of this bug. ***
Same problem under Linux, Mozilla 1.7b
I don't understand why the hidden controls do not work the same as text ones.

The HTML spec says:

The control's "current value" is first set to the initial value. Thereafter, the
control's current value may be modified through user interaction and scripts.

A control's initial value does not change. Thus, when a form is reset, each
control's current value is reset to its initial value.

----------------
It's obviously a bug of Mozilla.
I'm not a fan of IE, but at least Internet Explorer behaves correctly in this
case. I'm a J2EE developer and it's very important to me that hidden fields are
correctly reset to their ORIGINAL value!
*** Bug 258594 has been marked as a duplicate of this bug. ***
> but at least Internet Explorer behaves correctly

No, it does not.  It doesn't reset to the "value" attribute (as the HTML spec
says), but to some random magic value.

Mozilla is quite consistent with the spec in that it changes the value to the
value attribute when you reset.  The only issue is that setting .value changes
the value attribute (in both IE and Mozilla).

If we get some testing of alternative 2 from comment 4, we should be able to go
forward with this bug.  Alternative 1 is what we have already, and alternative 3
is a gross violation of the HTML spec.
Still doesn't work in Firefox 1.0 (Gecko/20041107)
Cant believe this has been left broken so long. I've just discovered 2K rows of 
bad data in our DB due to this bug. It needs to be fixed ASAP. Its as critical 
as a security exploit as it can mean that unknown to the user or site designed 
they are submitting invalid form data.
N.B. Bug 285623 is also a duplicate of this.
*** Bug 285623 has been marked as a duplicate of this bug. ***
This is still broken as of Gecko 20060516. 

It can be validly described as a bug because the HTML 4 spec states that "when a form is reset, each control's current value is reset to its initial value." It does not state that hidden <inputs> should be excluded from this.

http://www.w3.org/TR/html4/interact/forms.html#didx-form-1

The problem likely originates from the DOM2 HTML spec on HTMLInputElement,

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-6043025

which specifies load-time "default" properties for all <input> types EXCEPT hidden. Somebody was faithful to the DOM2's precise implementation at the expense of HTML's assertion that a reset reverts the entire form.

But this creates an unreasonable inconsistency in the DOM as well. Dynamically setting the "value" doesn't also update the "defaultValue" for any other types of form inputs. Nor does the DOM say that this happens for hidden inputs. 

A developer has no reason to expect hidden inputs to be deliberately unresettable. They should be consistent with other form inputs, both because it makes intuitive sense and to make the reset button work as advertised in HTML 4.
http://www.w3.org/TR/html4/interact/forms.html#initial-value
================================================================================
In general, a control's "initial value" may be specified with the control element's value attribute. However, the initial value of a TEXTAREA element is given by its contents, and the initial value of an OBJECT element in a form is determined by the object implementation (i.e., it lies outside the scope of this specification).

The control's "current value" is first set to the initial value. Thereafter, the control's current value may be modified through user interaction and scripts.

A control's initial value does not change. Thus, when a form is reset, each control's current value is reset to its initial value. If a control does not have an initial value, the effect of a form reset on that control is undefined.
================================================================================

Nowhere here does it say that "initial value" is concurrent with the value of the VALUE attribute (current value).

A control's initial value does not change.



 
> The problem likely originates from the DOM2 HTML spec on HTMLInputElement,
> 
> http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-6043025
> 
> which specifies load-time "default" properties for all <input> types EXCEPT
> hidden. Somebody was faithful to the DOM2's precise implementation at the
> expense of HTML's assertion that a reset reverts the entire form.

The definition of defaultValue does not state that defaultValue does not apply to hidden. The definition states:

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

This means:

"If it's TEXT, FILE, or PASSWORD, defaultValue is set to the form element's initial value (the value of the VALUE attribute).

The definition does not mention TYPE=HIDDEN.

The definition, which applies to HTMLInputElement, states:
[defaultValue] 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 definition of defaultValue applies to HTMLInputElement and TYPE=HIDDEN is an HTMLInputElement.

Problem still exists in Firefox/2.0.0.3 (rv:1.8.1.3 Gecko/20070309)
So whats the state of this bug its obviously a very nasty issue but has been sat here now for over 5 years!!
QA Contact: tpreston → layout.form-controls
Same problem in firefox 10 / MAC and Windows 7

I need reset the long form with hidden inputs in my project :(
Same problem in firefox 29 - this is really irritating!
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
You need to log in before you can comment on or make changes to this bug.