Closed Bug 212984 Opened 21 years ago Closed 21 years ago

printing too many pages: 137 pages instead of correct 4 from preview or PDFWriter

Categories

(Core :: Printing: Output, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.7final

People

(Reporter: script, Unassigned)

References

()

Details

(Keywords: regression, top100)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 What looks fine on print preview or printing to PDFWriter makes a big mess when actually printing to paper: It prints 137 pages, most of them containing the page headers only. Reproducible: Always Steps to Reproduce: 1. Goto quoted web site, sorry you need to create an account. I have been able to reproduce the problem with other pages, but this is the most striking example. 2. select "print preview" 3. print to printer Actual Results: 137 pages are printed instead of 4. Most pages just show the page header/footer. Print preview shows 4 correctly formated pages, as does PDFWriter, Expected Results: Print only 4 pages as displayed in print preview. This looks similar to bug 212719. Plse review my classification as major. For me this is really a show stopper for printing web pages as I might end up with 100 pages instead of just a few and let the printer run hot in an unprecictable way.
Mozilla build 2003121808 under w2k, http://msnbc.msn.com/id/3679341/ is only 5 pages long but will print out as 319. Ask me how I know. (That'll teach me not to use print preview, which also displays the 319 pages). Except for the first and last few pages which actually have some content, each page in between contains only the header, footer, and a single pixel-row of the images on the page (i.e. if there's a 198x298 image on the page, you're going to get about 298 pages). The printer used doesn't seem to matter, but for the record I tried the following drivers with the same bad results: HP LaserJet 5Si MX, Savin SLP38c PS, HP DeskJet 950, and HP LaserJet 6P. Setting this to "critical" because although the inadvertant printing of reams of paper at work isn't considered "loss of data", it could result in "loss of employment". Will try to come up with a test case...
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
I confirm the bug on FireBird: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+. Firebird shows identical behaviour to "Additional Comment #1 From rcummins@bcls.lib.nj.us 2003-12-19 11:04"
Now using Mozilla 1.6, the problem has changed somewhat - I'm consistently seeing 157 or 158 pages printed instead of more than 300. This bug seems to affect most of msnbc.com's articles, here are a few that exhibit this problem: http://msnbc.msn.com/id/3969486/ http://msnbc.msn.com/id/3907137/ http://msnbc.msn.com/id/3841686/ http://msnbc.msn.com/id/3939956/ http://msnbc.msn.com/id/3832808/ http://msnbc.msn.com/id/3081197/ http://msnbc.msn.com/id/3979904/ http://msnbc.msn.com/id/3842005/ ...also it seems that if in Print Preview you shrink the scale down to 20-25% it will suddenly go from 150+ pages to just one page. (I'm also going to change the original URL in this bug report, http://www.nytimes.com/2003/07/14/obituaries/14CART.html?tntemail1=&pagewanted=all&position=, to http://msnbc.msn.com/id/3679341/ because the latter doesn't require registration, and the former's content seems to have changed so that the problem doesn't manifest itself anymore.)
Flags: blocking1.7a?
Depends on: 231823
dbaron, any thoughts on who can help with this one?
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
I can reproduce the problem on solaris using the MSNBC URLs. Print preview and printing both produce 285 pages, most of them blank or containing just a sliver of content from the bar running down the left side of the page. The NYT URL doesn't produce the problem as noted in comment #3, so I've changed the sample URL. This looks like same as bug 228584 and bug 231823; both of these have reduced test cases. It seems that the problem appears both in printing and print preview on *nix, but (based on this report) only while printing on windows.
Blocks: 228584, 231823
No longer depends on: 231823
Flags: blocking1.7b?
Flags: blocking1.7b-
Flags: blocking1.7?
Blocks: 238237
*** Bug 238548 has been marked as a duplicate of this bug. ***
This problem doesn't occur on Phoenix 0.2 (2002-10-01 trunk) or Mozilla 1.1 but does on Phoenix 0.3 (2002-10-14 trunk) and Mozilla 1.2, I don't have any other old builds lying around so that's as close as I can get. I have two reduced testcases, one from the URL in this bug and one from bug 238548, I'll attach both since they are slightly different.
Keywords: regression
Attached file Testcase 1 (MSNBC) (deleted) —
*** Bug 232593 has been marked as a duplicate of this bug. ***
*** Bug 238778 has been marked as a duplicate of this bug. ***
Blocks: 216614
I can't reproduce this with a trunk 1.7 winxp build from yesterday. Both attachments print fine as does the first dupe but not the second. The current url is a 404 that prints fine, updating url to the url in the second dupe.
*** Bug 228970 has been marked as a duplicate of this bug. ***
*** Bug 231212 has been marked as a duplicate of this bug. ***
I've attached a patch that ought to fix this to bug 231823. (It had a simplified testcase first, so I've been treating it as the primary bug, sort of...) However, the mapping from pixels to inches seems to be different for me than for all of the testcase authors, so I tend to need to modify all the testcases by putting in larger pixel values to make them show the bug in the first place, so testing that my patch fixes the testcases here may be time-consuming...
Attached image Print Preview Overlap (deleted) —
The patch in bug 231823 definitely improves things. The testcases go from being 12 pages long to 3 pages however the print preview still shows large areas of blank space (e.g. in the first MSNBC testcase, page 2 contains nothing but the word "Test"). The URL field in this bug goes from 220 pages to 4 pages in print preview with the patch applied, though there are still seemingly unnecessarily large gaps (page 1 contains nothing but the header and the left column, page 2 contains nothing but the title, the image and its caption, pages 3 and 4 contain the article). The print preview also shows part of the text going outside the page (see the attached image, when printed the text from "for the Moon and Venus!" until the horizontal rule is ommitted). I have no idea if these issues are part of this bug or are covered in separate bugs but I thought I'd add them here just in case, sorry if this comment is not relevant.
They belong in separate bugs.
Fixed by checkin of fix for bug 231823 to trunk, 2004-04-13 13:47:52 -0700. Fixed by checkin of fix for bug 231823 to MOZILLA_1_7_BRANCH, 2004-04-16 14:21:09 -0700.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.7final
*** Bug 216614 has been marked as a duplicate of this bug. ***
Flags: blocking1.7?
*** Bug 238237 has been marked as a duplicate of this bug. ***
*** Bug 228584 has been marked as a duplicate of this bug. ***
*** Bug 243491 has been marked as a duplicate of this bug. ***
*** Bug 244187 has been marked as a duplicate of this bug. ***
*** Bug 198908 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: