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

RESOLVED FIXED

Status

()

Core
Printing: Output
--
major
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: mats, Assigned: Eli Friedman)

Tracking

(Blocks: 1 bug, {regression, testcase})

Trunk
x86
Linux
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [blocking1.9a1+])

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
 
(Reporter)

Comment 1

12 years ago
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
Severity: normal → major
Keywords: regression, testcase
(Reporter)

Comment 2

12 years ago
Created attachment 224593 [details]
Testcase #1
(Reporter)

Comment 3

12 years ago
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
Blocks: 244055
(Reporter)

Comment 4

12 years ago
Created attachment 224603 [details] [diff] [review]
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

12 years ago
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
(Reporter)

Updated

12 years ago
Flags: blocking1.9a1?
(Assignee)

Comment 6

12 years ago
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?

Updated

12 years ago
Blocks: 343334
Flags: blocking1.9a1? → blocking1.9+
(Assignee)

Comment 7

12 years ago
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.
(Assignee)

Comment 8

12 years ago
Created attachment 243735 [details] [diff] [review]
Patch

Okay, here's the patch.  Very straightforward, restores old behavior.
Assignee: printing → sharparrow1
Status: NEW → ASSIGNED
Attachment #243735 - Flags: review?(roc)
Comment on attachment 243735 [details] [diff] [review]
Patch

thanks!

the new textframe kills all this horrible code.
Attachment #243735 - Flags: superreview+
Attachment #243735 - Flags: review?(roc)
Attachment #243735 - Flags: review+
(Assignee)

Updated

12 years ago
Whiteboard: [checkin needed]
Whiteboard: [checkin needed] → [checkin needed] [blocking1.9a1+]

Comment 10

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

11 years ago
Checked in
(Assignee)

Comment 13

11 years ago
Should be fixed; reopen and/or comment if you're still having problems (the fix should be in today's nightlies.)
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed] [blocking1.9a1+] → [blocking1.9a1+]
You need to log in before you can comment on or make changes to this bug.