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

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Alec Flett]

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.

Comment 1

[Alec Flett]

actually, looks like all the work has been done, I guess it's just a bug in the
implementation.

Comment 2

[Alec Flett]

attaching a test case
this makes it really really easy

Comment 3

[Alec Flett]

Attachment: xul which demonstrates the problem

Comment 4

[David Hyatt]

I'll take it.  I know what's wrong.

Comment 5

[Nisheeth Ranjan]

Re-assigning this to Hyatt...

Comment 6

[David Hyatt]

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.

Comment 7

[David Hyatt]

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.

Comment 8

[David Hyatt]

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.

Comment 9

[David Hyatt]

Thanks for the awesome test case, btw, Alec.  Made it real easy to debug.

Comment 10

[rods (gone)]

Yes, thanks for the test case. Fix is in my tree

Comment 11

[rods (gone)]

Checkboxes are fixed, but the state of the which radio button is clicked 
within the radio group is still messed up

Comment 12

[rods (gone)]

This should be a PDT+ or PDT-, if script manipulates checkboxes and radiobuttons 
while they are hidden it doesn't work.

Comment 13

[rods (gone)]

This is a the same problem as bug 21945 and it is a PDT+

Comment 14

[leger]

Putting on PDT+ radar for beta1.

Comment 15

[rods (gone)]

One last small thing to fix and then I can close this out, should be able to do 
that today.

Comment 16

[rods (gone)]

fixed

Comment 17

[leger]

Updating QA contact.

Comment 18

[Paul MacQuiddy]

verified with my soon to be x-roomies excellent test case 2/18