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

VERIFIED DUPLICATE of bug 34297

Status

()

Core
HTML: Form Submission
P3
normal
VERIFIED DUPLICATE of bug 34297
17 years ago
17 years ago

People

(Reporter: jsp, Assigned: rods (gone))

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 17522 [details]
Test case
(Reporter)

Comment 2

17 years ago
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.

Comment 4

17 years ago
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?

Comment 7

17 years ago
If you use XBL, you won't lose the state. :)
(Assignee)

Updated

17 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Form control state lost if style specifies display: none → [FRMC]Form control state lost if style specifies display: none

Comment 8

17 years ago
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
(Reporter)

Updated

17 years ago
Keywords: correctness, mozilla1.0

Comment 12

17 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 14

17 years ago
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.
(Reporter)

Comment 15

17 years ago
Created attachment 26620 [details]
Better testcase for the primary problem.

Comment 16

17 years ago
This isnt dupe of bug #64322 but of bug #34297 ..
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 17

17 years ago

*** This bug has been marked as a duplicate of 34297 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 18

17 years ago
cleaning up, verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.