57269 - [FRMC]Form control state lost if style specifies display: none

Status: VERIFIED DUPLICATE of bug 34297

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

Description

[jsp]

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.

Comment 1

[jsp]

Attachment: Test case

Comment 2

[jsp]

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.

Comment 3

[Hixie (not reading bugmail)]

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.

Comment 4

[David Hyatt]

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

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 6

[Hixie (not reading bugmail)]

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?

Comment 7

[David Hyatt]

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

Comment 8

[Travis Reeder]

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;"> ).

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

this is the same as bug 34297

Comment 12

[Kevin Jacobs]

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.)

Comment 13

[Kevin McCluskey (gone)]

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

Comment 14

[jsp]

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.

Comment 15

[jsp]

Attachment: Better testcase for the primary problem.

Comment 16

[Vladimir Ermakov]

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

Comment 17

[Vladimir Ermakov]

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

Comment 18

[Vladimir Ermakov]

cleaning up, verifying