61320 - printing textfield widgets causes assertions

Status: RESOLVED WORKSFORME

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

Description

[Bradley Baetz]

Printing any page contain now prints two assertions, (one before and one after
the P string) per text field in the page:

###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2059
###!!! Break: at file nsFrame.cpp, line 2059

(the same assertion every times)

To reproduce, try printing www.google.com, either to a printer or to a file -
you'll get one assertion before and one after. Printing the new bug entry form
gives 6 assertions both before and after - there are 6 freetext fields,
including the bug # at the footer.

The document still prints.

Comment 1

[dcone (gone)]

Are you responsible for text widgets... if you are not.. do you know who is?

Comment 2

[rods (gone)]

reassigning

Comment 3

[rubydoo123]

assigning to anthony to help debug the assert

Comment 4

[anthonyd]

investigating.

anthonyd

Comment 5

[rubydoo123]

asserts should be cleaned up

Comment 6

[shrirang khanzode]

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

Comment 7

[anthonyd]

setting to mozilla 0.9.1

Comment 8

[Kathleen :Brade]

moving to milestone mozilla1.0; add helpwanted

Do these assertions still get triggered?

Comment 9

[Bradley Baetz]

Yes, these still get triggered (although the relevent line number is now line
2124)

Comment 10

[rubydoo123]

--> kin

Comment 11

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 12

[kinmoz]

Printing creates it's own set of frames for each element in the content tree ...
unfortunately this has the side effect of creating an editor for each text
widget on the page.

This assertion is being triggered by some code in the editor which requires a
widget so that it can QI it to an nsIKBStateControl interface and call
ResetInputState() to initialize IME.

The error generated by the assertion in nsFrame.cpp is propogated back to the
editor, and is ignored, so nothing really bad happens.

If we really wanted to pursue fixing this, for mozilla1.0, we'd probably have to
figure out somehow that our frame is created by a print context, and somehow set
flags on the editor to prevent IME initialization.

Note that editors are still needed during printing because it is what generates
the anonymous content nodes necessary to represent the contents of the text widgets.

Comment 13

[karnaze (gone)]

The pres context has a method for determining if it is printing. Marking 
mozilla1.0-, topembed-, future P2

Comment 14

[Jaime Rodriguez, Jr.]

Corfirming topembed- [T2] per EDT triage.