From Bugzilla Helper: User-Agent: Mozilla/4.08 [en] (WinNT; U ;Nav) BuildID: 2000101014 When printing an already-filled-out form, the radio button selections printed incorrectly (printed the first radio button every time instead of whichever was selected when print called) and all text fields printed plank even though filled out Reproducible: Always Steps to Reproduce: 1. Fill out text fields 2. select some radio buttons (vary between first, second, third and fourth in pultiple choice) 3. Print Actual Results: Forms printed wrong (blank, or wrong input) Expected Results: Printed what was filled out in text fields instead of blank placeholders. Printed correct selected radio button instead of first choice Please forgive lack of eloquence in this bug report!
This shud get fixed with 24406.Pls try a latest build and rechek, Thx.
Tried with today's build on windows. Agreed that ht radio button selection doe snot get printed. The first radio button appears selected when printed.
confirmed and resummarized
spam : changing qa to sujay (new qa contact for Printing)
content model for the radio buttons does not update the frame tree for the printout.
This happens on the Mac as well. It appears as if the act of preparing to print actually causes the radio buttons to be reset to their initial values. The buttons are reset in the window too, not just on the printed page.
this is an important issue for topembed clients. please retarget it to sometime sooner...
Worse yet, the radio group gets "reset" to its original values. Steps: 1) Select radio button "Two" 2) Print page (notice that the "One" radio is now selected 3) Submit form just to varify which radio has been set 4) Note the echo show one is now selected
This patch should really be applied to the 9.2 branch. Extremely low risk patch
This is strange is this still a bug? I see the bug now, but that is only because we are now in "Standard" for all form controls. But if I revert back to Quirks and Standard mode, it works fine. When the bug was open we used quirks and this page had a trad. DTD, so it would have also been in Quirks mode. Ignore the patch here I will fix that probalem with Bug 96367. When Bug 96367 gets fixed I think will be fixed.
There are really two issues: 1) The printing PresContext was getting it's compatability mode set correctly and therefore was always printing in standard mode (the lastest patch here fixes that) 2) Whenever radios were being printed in standard they "reset" the radios on the screen and then the history picked up the wrong values and the print out was wrong. This will be fix by Bug 96367
r=dcone. I ran and helped with this.. this is definitly the solution.
a=asa on behalf of drivers.
fixed on trunk and .92 branch.
Eugene, does this work for you now? please try in latest build...lemme know.. thanks.
verified in 9/4 trunk build.
Verified in 9/5 trunk (Gecko/20010905) Thanks!