Closed Bug 267352 Opened 18 years ago Closed 18 years ago

printing doesn't print form inputs

Categories

(Core :: Printing: Output, defect)

1.7 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: shaver)

References

Details

(4 keywords, Whiteboard: need 1.7 branch landing)

Attachments

(1 file)

printing doesn't print form inputs

to reproduce:

1) go to https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox
2) start filling out a bug, summary, url, cc, description etc.
3) hit print

you won't see the text values in the forms on paper.

note:  if you print preview, you will see the values.

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041026 Firefox/1.0

this used to work, but I can't say for sure when it regressed.
ben / asa, do you think this sort of printing regression should block 1.0?
Flags: blocking-aviary1.0?
we need to figure out when this might have regressed, and what caused the
regression...  any ideas?
Tracy sees this on today's build on the Mac. We are investigating the regression
window.
for a simple test case, this also occurs at http://www.google.com
OS: Windows XP → All
Hardware: PC → All
OS: All → Windows XP
Hardware: All → PC
This worked in Firefox PR1, so it's a post-PR1 regression, it seems.
this regressed btwn 2004100409-0.9+ (works) and 2004100509-0.9 (broken) builds
--tested on linux fc2.
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
on the blocker list until we know more.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Looks like this was caused by bug 228557, backing out that fix (plus the fix for
263060) makes printing contain form control values again.
Blocks: 228557
I have learned much about event queue services today.  Please find enclosed a
patch which makes printing hold its horses until async initializations have
completed.
Assignee: firefox → shaver
Status: NEW → ASSIGNED
Comment on attachment 164643 [details] [diff] [review]
Flush the event queue to be sure that editor initialization has completed before we actually print.

r=darin with one change:

use the PR_STATIC_CALLBACK macro since you don't want to be exporting those
callback functions.
Attachment #164643 - Flags: review+
Comment on attachment 164643 [details] [diff] [review]
Flush the event queue to be sure that editor initialization has completed before we actually print.

sr=jst with PR_STATIC_CALLBACK(void *) etc used.
Attachment #164643 - Flags: superreview+
Attachment #164643 - Flags: approval-aviary?
Comment on attachment 164643 [details] [diff] [review]
Flush the event queue to be sure that editor initialization has completed before we actually print.

after discussing in aviary meeting today, we don't want to risk this patch and
would like to revert the change at bug 228557.
Attachment #164643 - Flags: approval-aviary? → approval-aviary-
The fix for bug 228557 is now backed out, so this is no longer a problem on the
aviary branch.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Keywords: fixed-aviary1.0
confirmed fixed on Firefox branch with builds:
Win 2004-11-05-07-0.11
Mac 2004-11-05-06-0.11
Comment on attachment 164643 [details] [diff] [review]
Flush the event queue to be sure that editor initialization has completed before we actually print.

a=roc for 1.8a5
Fixed on trunk for 1.8a5.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 276452 has been marked as a duplicate of this bug. ***
It seems we forgot about the 1.7 branch here :/ (Bug 228557 was only backed out
on aviary branch as far as i read it on that bug; but the fix was checked into
1.7 branch, too). So what now (i dont know if backing out that patch is still
possible or if too much checkins already happened)?
Component: General → Printing
Flags: review+
Product: Firefox → Core
Version: 1.0 Branch → 1.7 Branch
Bug has NOT been fixed, still lack of fix for 1.7 branch.
Flags: blocking1.7.6?
*** Bug 277931 has been marked as a duplicate of this bug. ***
Why is this marked "resolved" when I cannot download a fixed version?
(In reply to comment #21)
> Why is this marked "resolved" when I cannot download a fixed version?

It is fixed on Firefox and Mozilla Trunk builds. Don't worry, i'll hope this bug
will be fixed for 1.7.6.
*** Bug 278305 has been marked as a duplicate of this bug. ***
*** Bug 278697 has been marked as a duplicate of this bug. ***
*** Bug 278852 has been marked as a duplicate of this bug. ***
As of a follow-up to comment #22: is this fix going to be backported to the 1.7
branch (and be included in 1.7.6)?

We're stuck between a rock and a hard place here--many people are complaining
about this problem, but we don't want to revert to a version of Mozilla with
known security vulnerabilities...
*** Bug 279779 has been marked as a duplicate of this bug. ***
Flags: blocking1.7.6? → blocking1.7.6+
Should we backport this fix for 1.7.6 or backout bug 228557 from 1.7.6 as was
done for aviary?
Given that bug 228557 caused bug 267225 too, I would say we should back it out
of 1.7.6....
Whiteboard: need 1.7 branch landing
*** Bug 280970 has been marked as a duplicate of this bug. ***
*** Bug 282321 has been marked as a duplicate of this bug. ***
Should now be fixed for 1.7.6. Please test it.

MOZILLA_1_7_BRANCH 2005-02-17 17:08	jst%mozilla.jstenback.com
Backing out the fix for bug 228557 (and bug 263060) since it caused regression
bug 267352. This was backed out of the aviary branch some time ago.
a=asa@mozilla.org
Keywords: fixed1.7.6
Confirming with current 1.7 branch build, print preview displays text in input
fields and printing it out shows the text on the paper, too :).
So..  Bug 228557 as never checked in on trunk, but t his was.  Do we still need
this on trunk?
vrfy'd fixed using firefox 1.0.1 and mozilla 2005031011-1.7 builds on linux fc3.
Status: RESOLVED → VERIFIED
mistakenly removed fixed1.7.6 --pardon the bugspam. set your filter/quicksearch
to "ZippidityDooDahHey" to catch these for easy removal/etc/
Keywords: fixed1.7.6
Depends on: 325991
You need to log in before you can comment on or make changes to this bug.