340564 - Print/Print Preview does not print text in <input text> or <textarea>

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Mats Palmgren (inactive)]

Comment 1

[Mats Palmgren (inactive)]

Print/Print Preview does not print text in <input text> or <textarea>.

STEPS TO REPRODUCE
1. load attached testcase
2. Print or Print Preview

ACTUAL RESULTS
Two empty boxes

EXPECTED RESULTS
Some text in the boxes

PLATFORM AND BUILDS TESTED
Bug occurs in Seamonkey trunk Linux (GTK2)

The regression range is 2006-03-31-06 -- 2006-04-01-01
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-31+05%3A00&maxdate=2006-04-01+02%3A00&cvsroot=%2Fcvsroot

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 3

[Mats Palmgren (inactive)]

Bug 244055 caused this regression.

Backing out the text frame change from that bug fixes it:
cvs up -j1.563 -j1.562 layout/generic/nsTextFrame.cpp

Comment 4

[Mats Palmgren (inactive)]

Attachment: wip1

This makes the text appear again, but I suspect it's not a complete fix
since I now see other strange things in Print Preview, like being able to select
the text inside the text controls and the selection is highlighted.

Comment 5

[Raj Bhaskar]

I also see this on Windows trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060604 MultiZilla/1.8.2.0i SeaMonkey/1.5a

Comment 6

[Eli Friedman]

The patch to Bug 244055 misuses the isPaginated variable from GetTextInfoForPainting, which is only true for selection printing, to !isDynamic, which is true for all kinds of printing.  (Yes, I do hate this code.)

Alex, what exactly was the intent of the PaintAsciiText/PaintUnicodeText changes?  Are they actually needed for page layout mode to work?

Comment 7

[Eli Friedman]

Okay, so now this is blocking 1.9.  If there isn't any response from Alexandre Tremon on my previous comment, I'd say the correct course is to back out the nsTextFrame changes from bug 244055.

Comment 8

[Eli Friedman]

Attachment: Patch

Okay, here's the patch.  Very straightforward, restores old behavior.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 243735 [details] [diff] [review]
Patch

thanks!

the new textframe kills all this horrible code.

Comment 10

[David Reitter]

I see this in current Camino builds (2006102101) as well - however, it only affects text in input fields where a word was marked as possible typo by the spell-checker. All other fields print off fine. (Not sure if this is actually the same bug.)

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Did this patch get checked in?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Checked in

Comment 13

[Eli Friedman]

Should be fixed; reopen and/or comment if you're still having problems (the fix should be in today's nightlies.)