58002 - Radio button selection does not get printed correctly(first button appears selected) [print][content]

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P3)

Description

[eyv]

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!

Comment 1

[shrirang khanzode]

This shud get fixed with 24406.Pls try a latest build and rechek, Thx.

Comment 2

[shrirang khanzode]

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.

Comment 3

[shrirang khanzode]

confirmed and resummarized

Comment 4

[shrirang khanzode]

spam : changing qa to sujay (new qa contact for Printing)

Comment 5

[dcone (gone)]

content model for the radio buttons does not update the frame tree for the 
printout.

Comment 6

[Brian Nesse (gone)]

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.

Comment 7

[Gagan]

this is an important issue for topembed clients. please retarget it to sometime
sooner... 

Comment 8

[rods (gone)]

Attachment: reduced testcase with submit

Comment 9

[rods (gone)]

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

Comment 10

[rods (gone)]

Attachment: patch file (simple patch)

Comment 11

[rods (gone)]

This patch should really be applied to the 9.2 branch. Extremely low risk patch

Comment 12

[rods (gone)]

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.

Comment 13

[rods (gone)]

Attachment: patch

Comment 14

[rods (gone)]

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

Comment 15

[dcone (gone)]

r=dcone.  I ran and helped with this.. this is definitly the solution.

Comment 16

[Marc Attinasi]

sr=attinasi

Comment 17

[Asa Dotzler [:asa]]

a=asa on behalf of drivers.

Comment 18

[dcone (gone)]

fixed on trunk and .92 branch.

Comment 19

[sujay]

Eugene, does this work for you now? please try in latest build...lemme know..
thanks.

Comment 20

[sujay]

verified in 9/4 trunk build.

Comment 21

[eyv]

Verified in 9/5 trunk (Gecko/20010905)
Thanks!