printing textfield widgets causes assertions

RESOLVED WORKSFORME

Status

()

P2
normal
RESOLVED WORKSFORME
18 years ago
5 months ago

People

(Reporter: bbaetz, Assigned: kinmoz)

Tracking

({helpwanted, topembed-})

Trunk
Future
x86
Linux
helpwanted, topembed-
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [assert] [T2])

(Reporter)

Description

18 years ago
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

18 years ago
Are you responsible for text widgets... if you are not.. do you know who is?
Assignee: dcone → rods

Comment 2

18 years ago
reassigning
Assignee: rods → beppe

Comment 3

18 years ago
assigning to anthony to help debug the assert
Assignee: beppe → anthonyd
Target Milestone: --- → mozilla0.9

Comment 4

18 years ago
investigating.

anthonyd
Status: NEW → ASSIGNED

Comment 5

18 years ago
asserts should be cleaned up

Comment 6

18 years ago
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay

Comment 7

18 years ago
setting to mozilla 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

18 years ago
Blocks: 64841

Comment 8

18 years ago
moving to milestone mozilla1.0; add helpwanted

Do these assertions still get triggered?
Keywords: helpwanted
Target Milestone: mozilla0.9.1 → mozilla1.0
(Reporter)

Comment 9

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

Updated

18 years ago
Whiteboard: [assert]
Target Milestone: mozilla1.0 → mozilla0.9.3

Updated

18 years ago
Target Milestone: mozilla0.9.3 → mozilla1.0

Comment 10

17 years ago
--> kin
Assignee: anthonyd → kin
Status: ASSIGNED → NEW
(Assignee)

Comment 11

17 years ago
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

17 years ago
Keywords: topembed

Updated

17 years ago
Keywords: mozilla1.0+
(Assignee)

Comment 12

17 years ago
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

17 years ago
The pres context has a method for determining if it is printing. Marking 
mozilla1.0-, topembed-, future P2
Keywords: mozilla1.0+, topembed → mozilla1.0-, topembed-
Priority: P3 → P2
Target Milestone: mozilla1.0.1 → Future

Comment 14

16 years ago
Corfirming topembed- [T2] per EDT triage.
Whiteboard: [assert] → [assert] [T2]
QA Contact: sujay → printing

Updated

5 months ago
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.