Closed Bug 27063 Opened 20 years ago Closed 20 years ago

radio buttons & checkboxes don't maintain state when the frame goes away

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: alecf, Assigned: rods)

References

Details

(Whiteboard: [PDT+] 2/15)

Attachments

(1 file)

I have, in XUL:

<html:div style="display: none" id="noframe">
  <html:input type="checkbox" name="test1"/> test 1
</html:div>

if I write this javascript:
document.controls["test1"].checked = true;
document.getElementById("noframe").style.display = "block";

then test1 is not checked when it appears. If I switch the order of these
statements, the checkbox is checked.

I believe this is just like the problem we were having with gfx text widgets
where their value won't save/restore out of the frame correctly, and doing a
similar operation on gfx text widgets seems to behave correctly.

I'm cc'ing hyatt because he may know more about this, or at least how to solve
it.

I'm investigating as well. I really really want this bug fixed (because I have
to do some TERRIBLE hacks in the mail account manager to work around this) so I
am willing to even do the work if someone just spends 5 minutes to me at the
right code and an example of how the gfx text frame does it.
actually, looks like all the work has been done, I guess it's just a bug in the
implementation.
attaching a test case
this makes it really really easy
I'll take it.  I know what's wrong.
Status: NEW → ASSIGNED
Target Milestone: M14
Re-assigning this to Hyatt...
Assignee: nisheeth → hyatt
Status: ASSIGNED → NEW
I spoke too soon.  It looks like the code (from the pres state perspective at 
least) is set up correctly.  Maybe it's a problem with the checkbox frame.
Status: NEW → ASSIGNED
Alex, can you work around your problem by using visibility: collapse instead of 
display: none?  You'll get better performance if you use visibility: collapse 
anyway, since you won't be destroying the layout frames.
Another interesting frame interaction bug.  Scoped it out for ya, rod.  What's 
happening in this case is that the checkbox restores its state properly from the 
presState, and life is good... but then we hit a function called 
PostCreateWidget, and it goes off and gets the default checked state from the 
input element... and then subsequently blows away any value you've previously 
restored via the history/pres state.

I bet the same thing is happening for radio buttons, although I didn't verify 
yet.  This should be pretty easy to fix.

Reassigning to rod.
Assignee: hyatt → rods
Status: ASSIGNED → NEW
Thanks for the awesome test case, btw, Alec.  Made it real easy to debug.
Yes, thanks for the test case. Fix is in my tree
Status: NEW → ASSIGNED
Whiteboard: fix is in my tree
Checkboxes are fixed, but the state of the which radio button is clicked 
within the radio group is still messed up
Whiteboard: fix is in my tree
Depends on: 27262
This should be a PDT+ or PDT-, if script manipulates checkboxes and radiobuttons 
while they are hidden it doesn't work.
Keywords: beta1
This is a the same problem as bug 21945 and it is a PDT+
Putting on PDT+ radar for beta1.


Whiteboard: [PDT+]
One last small thing to fix and then I can close this out, should be able to do 
that today.
Whiteboard: [PDT+] → [PDT+] 2/15
fixed
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updating QA contact.
Component: Layout → XP Toolkit/Widgets: XUL
Keywords: verifyme
QA Contact: petersen → paulmac
verified with my soon to be x-roomies excellent test case 2/18
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: paulmac → xptoolkit.widgets
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.