Closed Bug 158209 Opened 24 years ago Closed 3 years ago

Reset hidden value don't work

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.4alpha

People

(Reporter: topperlu, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

Testcase
755 bytes, text/html
Details
<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>.
URL: http://www.q1n.org/mozilla/bugs/bug_1...
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
Assignee: john → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 15 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

Given all browsers seem to behave the same way now we're unlikely to act on this. Please reopen if I got that wrong tho.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(emilio)
Resolution: --- → WONTFIX

All browsers seem to behave the same, huh? I missed the test results.

Browsers deviating from specs is a problem. Don't copy other browsers. That was a common bad decision of the past.

HTML5 came along and, although some contributors were not so good (e.g. AVK and Doug Schepers), testing led to specs that could be depended on.

The deviation is that when setting a HIDDEN's .value property, the attribute is updated.

The reset algorithm for input elements sets the value of the element to the value of the value content attribute. [html5 reset], but this is taking the value from the content attribute, which was changed.

The problem is that with HIDDEN, the VALUE attribute reflects the value property.

  1. Load the test case
  2. Click Change It.
  3. Open Console

currValue.getAttribute("value")
'oldValue'
hiddenField.getAttribute("value")
'newValue'

[html5 reset] https://html.spec.whatwg.org/multipage/input.html#the-input-element#the-input-element:concept-form-reset-control

(HTML 5 also says "the select element does not have a value", but it does. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#a-form-control's-value:the-select-element)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: