Closed
Bug 212821
Opened 22 years ago
Closed 21 years ago
after printing only page 1, pages 2-8 are missing from print preview
Categories
(Core :: Print Preview, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: suzyp, Unassigned)
References
()
Details
(Keywords: fixed1.4.1)
Attachments
(1 file)
(deleted),
patch
|
mkaply
:
review+
roc
:
superreview+
mkaply
:
approval1.4.1+
mkaply
:
approval1.5+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
viewed url above, hit print preview. 8 pages worth of stuff. Decided to print
only page 1. printed, then closed Print preview. changed my mind and decided
to print a couple later pages. Hit print preview. Now only page 1 shows up in
preview. All 8 pages get sent to printer. Tried Refreshing web page, tried
going to another page then coming back. Still could only see page 1 in preview.
Reproducible: Always
Steps to Reproduce:
1.view url
2. hit print preview
3. hit print, select print page 1
4. close print preview
5. open print preview
Actual Results:
only page 1 is visible; all 8 will go to printer
Expected Results:
showed all 8 pages in preview
workaround: close and reopen Mozilla
Comment 1•22 years ago
|
||
seems to me to be the same problem as bug# 211409
Reporter | ||
Comment 2•22 years ago
|
||
I agree. I tried to do a search before I entered the bug. I obviously have a
bit to learn. What's protocol here? I hate to resolve it since there is more
info here.
This bug is easy to duplicate and still exists on the trunk, win32 build
2003080104. If the user chooses to print just one page of a multipage document,
then they can only print preview one page for the rest of their browser session
*regardless of what site they're viewing*. To drive the point home, it's not
just the web page that they originally print previewed that's broken, it's every
page afterwards as well. The only workaround is to exit and restart Mozilla.
Changing severity to critical, as this is dataloss.
Severity: minor → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 214813 has been marked as a duplicate of this bug. ***
*** Bug 211409 has been marked as a duplicate of this bug. ***
Changing OS to "All", as I just verified the latest build for Linux exhibits
this problem as well.
OS: Windows XP → All
Comment 7•21 years ago
|
||
rcummins, can you identify the last working build so we can figure out what
regressed this (is it a regression from previous releases?)
Severity: critical → major
I thought it was a regression that occurred somewhere between 1.3 - 1.4a, but I
was mistaken.
This bug doesn't exist in Mozilla 1.0, 1.0.1, or 1.0.2.
It does exist in Mozilla 1.1a, 1.1b, 1.1, 1.2, 1.3, and 1.4. I would be happy
to check the nightlies between 1.0 and 1.1a, if I thought they existed anywhere
anymore. Such ancient history probably isn't going to be of much use.
Updated•21 years ago
|
Flags: blocking1.5b?
Flags: blocking1.5b-
Flags: blocking1.5?
*** Bug 186394 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
For 1.4 Linux (current Debian build), the preview always shows the page range
that was printed last. If you print "all" pages (to a file in this case),
they'll all show up in the preview. The problem persists even if another page is
viewed and is not limited to "1st page printed".
Comment 11•21 years ago
|
||
Response to Asa's question in comment #7: For as long as I have been using
Phoenix and Firebird (I started with Phoenix 0.3) this problem has existed.
Whatever page or range of pages I print, all subsequent previews of all
subsequent sites are limited to that page or range of pages.
Comment 12•21 years ago
|
||
not gonna make 1.5. dbaron or roc, can you guys look into this?
Flags: blocking1.5? → blocking1.5-
Comment 13•21 years ago
|
||
Here's what's happening -
When you print a page range, the browser remembers this and the start and end
pages. When you print again, these values do not show up in the print dialog
because the dialog resets the start and end page back to 1 or leaves the page
range text fields blank. But... If you do a print preview, the code checks
for a selection and if there is one will set the print range back to all pages,
but doesn't do this if there was a page range selected last time you printed.
So all pages aren't being displayed, just the range of pages selected from the
previous print. In my patch I went ahead in PrintPreview() in nsPrintEngine.cpp
and always set the print range to all pages so every time you bring up Print
Preview all pages will display.
Comment on attachment 130875 [details] [diff] [review]
nsPrintEngine.cpp - set print range to all pages every time in Print Preview
Looks good to me.
Attachment #130875 -
Flags: superreview+
Attachment #130875 -
Flags: review?(dbaron)
Comment 15•21 years ago
|
||
Comment on attachment 130875 [details] [diff] [review]
nsPrintEngine.cpp - set print range to all pages every time in Print Preview
r=mkaply
a=mkaply for 1.5 and 1.4.1
Attachment #130875 -
Flags: review?(dbaron)
Attachment #130875 -
Flags: review+
Attachment #130875 -
Flags: approval1.5+
Attachment #130875 -
Flags: approval1.4.x+
Comment 16•21 years ago
|
||
fixed on branch and trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•