If radio buttons or checkboxes are set by the user, then made invisible by changing the style to include "display: none", their state is lost. (Other controls may also be affected; I didn't check.) This has two manifestations: - If the form is submitted while the controls are not displayed, the data for the invisible controls is not submitted, though 17.13.2 of the HTML 4.01 spec says, "Hidden controls and controls that are not rendered because of style sheet settings may still be successful." - If the controls are made visible again, they revert to their original state, not the state set by the user.

State retention turns out to be a problem only if the controls are in a <span>. If the <span> in the test case is changed to a <div>, the controls have the same state after the div is hidden and shown as the user set before hiding. However, the data still doesn't get submitted if the div is hidden. This probably is two bugs, not one.

cc'ing hyatt for XBL loving. rods, hyatt: This also occurs when a form widget is removed from the DOM. We should be keeping the state of the widgets (even with ender widgets) with the actual node at all times. In fact, I would argue that the actual 'value' attribute should change; but I don't know if I am correct there.

When removed from the DOM, IMO the state could be lost. This would be permissible. I don't have a problem with that.

But fixing this problem would probably fix DOM removal issues too.

Hyatt: How would you move an <input> element from one <div> to another, without losing the state? What about if you want to move all the children of an element to some other element, and one of them happens to be a form control?

If you use XBL, you won't lose the state. :)

This also occurs when part of a form is hidden (ie: display = "none";) when the page is first displayed and the SELECTED property or CHECKED property in the select or input field is set. When that portion is then set to "block", the form elements show up as if the SELECT had never been set on one of the options so it always shows the first thing in the select list, instead of the selected one. The display attribute in my case is set in a table (ex. <table style="display:none;"> ).

*** Bug 58616 has been marked as a duplicate of this bug. ***

*** Bug 59723 has been marked as a duplicate of this bug. ***

this is the same as bug 34297

I just reported a similar issue in bug #64322. It deals with the 'value' attribute being reset to 'defaultValue' when an HTMLFormElement is inserted into the DOM. In previous comments on this bug it was stated that losing state "would be permissable". Having read the DOM standards, I cannot see how this could be so. This is particularly clear in the context of bug #64322. Unless something more concrete can be found in the standards, I believe that the current behavior is incorrect and non-standard conforming. It seems to conflict with the DOM HTML specs, which do not include such lattitude for changing an HTMLFormElement 'value'. It also seems that this bug has roots in the construction order logic of pre-DOM browser elements. It even worked, for the most part, when the DOM was created from the HTML parser, since much of the build order was the same. Now that DOM elements can be created in strange orders, moved around, hidden, etc., the assumptions built in to the code no longer apply. The GUI controls are now a client of the DOM, and must act accordingly by and request intial values from it, obey it when its attributes change, and properly post changes to it. Anything else is fiction. (I know I'm using strong language, but I feel very strongly that the current behavior is wrong, and rationalizing it without a shred of support from standards it is even more wrong.)

*** This bug has been marked as a duplicate of 64322 ***

While the second part of the original report may well be a duplicate, I doubt the first is. To recap, the first part (which is the part that I most care about) states that data for invisible controls is not submitted, contrary to 17.13.2 of the HTML 4.01 spec ("Hidden controls and controls that are not rendered because of style sheet settings may still be successful"). The bug described in the summary can be demonstrated without any JavaScript. I'll attach a new testcase. (The first one did a better job of illustrating the second problem, in retrospect.) Please reconsider marking this as a duplicate of bug 64322.

This isnt dupe of bug #64322 but of bug #34297 ..

*** This bug has been marked as a duplicate of 34297 ***

cleaning up, verifying