This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 15450 as part of operation convergence. Originally filed: 2012-01-07 11:41:00 +0000 Original reporter: Giorgio <giorgio.liscio@email.it> ================================================================================ #0 Giorgio 2012-01-07 11:41:50 +0000 -------------------------------------------------------------------------------- my case is, briefly <form> <input name="aaa" value="XXX"> <input type="submit" value="Save"> <input type="reset" value="Reset"> </form> user changes value of "aaa" from XXX to YYY in a "web 1.0" form the page will be reloaded and this is ok. but in my case, this form will be sent by xhr, then if "save" will be successful I have to loop manually over every data holder (texts, checkboxes, selects...) and set: theinput.defaultValue = theinput.value; otherwise the Reset button will reset the "aaa" value to "XXX", thats not what I want, because I've saved the form. so a form's interface method like HTMLFormElement.setCurrentValuesAsDefaultValues(); would be really cool. I hope this helps ================================================================================ #1 Kornel Lesinski 2012-01-09 22:30:40 +0000 -------------------------------------------------------------------------------- I'm curious what is your use case for including Reset button in the form? Is saving of entire form granular enough? If you're already using JavaScript to serialize the form, why not use that to restore previous values? Are there existing libraries (jQuery plugins, etc.) that solve this problem? ================================================================================ #2 Ian 'Hixie' Hickson 2012-02-03 06:28:48 +0000 -------------------------------------------------------------------------------- I've run into this too — in particular, Firefox seems very eager to fill in form fields and restore form control state even when they're not in <form>s, including button disabled states, etc, so that you can basically never guess when the page loads what state a form control is going to be in. It's kinda annoying. Not sure what to do about it. ================================================================================
My comment above is a complete non-sequitur. Ignore it. The workaround in the meantime is to manually set the "value" content attribute to the value of the .value IDL attribute, FWIW. (And similarly for checkboxes, textareas, select boxes, etc.)
I'm deferring this to later, mostly in the hope of finding out how common this problem actually is and whether it's worth fixing.
I haven't heard any developer requests about this. Looks like "reset" in general is going out of favour. I'm punting this for now. If you have any information that suggests we should add this, please add it to the bug. If there's no new compelling information, I'll probably end up WONTFIXing this, given how relatively easy it is to work around it and how rarely it seems to be needed.
One thing that would be interesting here is if anyone can find examples of people working around this limitation, e.g. by manually resetting a form instead of calling the form.reset() API.
Closing per comment 3. Please do reopen if you have the information request in comment 4.