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
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
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.
I also see this on Windows trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060604 MultiZilla/126.96.36.199i SeaMonkey/1.5a
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?
Flags: blocking1.9a1? → blocking1.9+
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.
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.
Whiteboard: [checkin needed] → [checkin needed] [blocking1.9a1+]
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.)
Did this patch get checked in?
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.