Printing out driving directions results in last page printing out extremely slowly

VERIFIED WORKSFORME

Status

()

Core
Printing: Output
P3
normal
VERIFIED WORKSFORME
17 years ago
4 years ago

People

(Reporter: Marc Attinasi, Assigned: Stuart Parmenter)

Tracking

Trunk
mozilla1.0
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
This bug is a spin-off from bug 74738. The temporary patch introduced for bug
74738 makes the driving directions print out, but the last page never finishes
printing. The testcases from bug 74738 print out OK, however, so some narrowing
down of the MapQuest driving directions might be in order.

The change for bug 74738 incidentally, is just to add a rule to html.css to make
floated tabled unfloated. It makes little sense that that could cause such a new
problem in printing (the current problem is that the last page never completes
at the printer, even though the print dialog goes away).
(Reporter)

Comment 1

17 years ago
Created attachment 39755 [details]
MapQuest page: prints OK from local file... isn't that special?
(Reporter)

Comment 2

17 years ago
Interesting: printing the testcase on Win2K the first 3 pages print out really
fast (less than 20 seconds) then I looked at the printer control window and
noticed that the last pages was actually printing, just really really slowly. It
took about 4 minutes to print. I could see the size listing very slowly
increasing, that was my clue that it was working.

Sujay, can you check if the last page will print if you wait long enough?
Obviously, it is still a bug, but it could be very different...
Status: NEW → ASSIGNED
(Reporter)

Comment 3

17 years ago
Updated summary since it appears the page is printing, just very slowly.
Summary: Printing out driving directions results in last page not printing → Printing out driving directions results in last page not printing (or printing out extremely slowly)

Comment 4

17 years ago
yes I also noticed that as I picked up my print job, the last page was
missing..however, there was a green light(processing) blinking at the
printer....this means the last page was still processing...

Comment 5

17 years ago
target milestone?
(Reporter)

Comment 6

17 years ago
Setting to Mozilla 1.0 and sending to dcone, the printing dude.

My hope is that this bug will become moot when we fix it so floated blocks can
be continued across pages (bug 87374). But then, it could be that the very slow
printing is due to something altogether different - I dunno.
Assignee: attinasi → dcone
Status: ASSIGNED → NEW
Priority: -- → P2
Summary: Printing out driving directions results in last page not printing (or printing out extremely slowly) → Printing out driving directions results in last page printing out extremely slowly
Target Milestone: --- → mozilla1.0

Updated

16 years ago
Blocks: 74634

Comment 7

16 years ago
still happening in 11/7 builds.

Comment 8

16 years ago
If I load the attachment in mozilla and print I will se the slowness? I just 
printed from mfcembed to a postscript file and it printed quickly.
Status: NEW → ASSIGNED

Comment 9

16 years ago
using 4/4 build of netscape

1) launch netscape
2) jump to Netscape home page
3) click on Maps
4) enter FROM and TO fields
5) Click Map It!
6) File | Print

go get the output and you'll notice that the last page doesn't print out
at all....green light on printer keeps blinking...

Comment 10

16 years ago
There are two small images that are "tiled" in one of the images is 2x2 and I 
think it is causing most of the slowness AND causing PostScript files to be 
rather large.


I stopped in the debugger several times while painting and it stopped here:

GDI32! 77f6d125()
USER32! 77e18815()
NTDLL! 77f9f04b()
nsImageWin::Draw(nsImageWin * const 0x0346e288, nsIRenderingContext & {...}, 
void * 0x033b25c0, int 0, int 0, int 2, int 2, int 4136, int 1398, int 2, int 2) 
line 535
nsImageWin::DrawTile(nsImageWin * const 0x0346e288, nsIRenderingContext & {...}, 
void * 0x033b25c0, int 0, int 0, const nsRect & {...}) line 725
nsRenderingContextImpl::DrawTile(nsRenderingContextImpl * const 0x02a25590, 
imgIContainer * 0x029ebf20, int 0, int 0, const nsRect * 0x0012c5bc) line 794 + 
43 bytes
nsCSSRendering::PaintBackground(nsIPresContext * 0x0344fd50, nsIRenderingContext 
& {...}, nsIFrame * 0x034f74ac, const nsRect & {...}, const nsRect & {...}, 
const nsStyleBackground & {...}, const nsStyleBorder & {...}, int 0, int 0) line 
2647
nsTableCellFrame::Paint(nsTableCellFrame * const 0x034f74ac, nsIPresContext * 
0x0344fd50, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 390 + 37 bytes
nsTableRowFrame::PaintChildren(nsIPresContext * 0x0344fd50, nsIRenderingContext 
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay, 
unsigned int 0) line 657
nsTableRowFrame::Paint(nsTableRowFrame * const 0x034b0fa8, nsIPresContext * 
0x0344fd50, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 609
nsTableRowGroupFrame::PaintChildren(nsIPresContext * 0x0344fd50, 
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 314
nsTableRowGroupFrame::Paint(nsTableRowGroupFrame * const 0x03659110, 
nsIPresContext * 0x0344fd50, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 267
Assignee: dcone → pavlov
Status: ASSIGNED → NEW

Comment 11

16 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 12

16 years ago
don't move bugs that are in the 1.0 dependency tree. sorry.

Target Milestone: mozilla1.0.1 → mozilla1.0
(Assignee)

Comment 13

16 years ago
don?  is this still the case with the current image stuff?
Priority: P2 → P3

Comment 14

16 years ago
just tried it again and it seems to work fine using 2/22 build.

all pages print out 

we can close this bug out...

Comment 15

16 years ago
I think this is fixed.... I will mark.. WFM.. based on all the new fixes for the 
images.  Open again if this is a problem.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 16

16 years ago
v
Status: RESOLVED → VERIFIED

Comment 17

16 years ago
Hmm... This bug is still referenced under Printing in the releasenotes for 1.1.

Comment 18

15 years ago
This bug still referenced in release notes for 1.2b

Comment 19

15 years ago
I have a problem where the last page (or two) don't print at all. If I print to
disk, it looks like a complete file, but still cuts off the end when I print
with a2ps -1. a2ps on other files works fine.

Red Hat 8.0
Mozilla/1.0.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Comment 20

15 years ago
Regarding comment 19:
After the imminent 1.2-release, try that version - quite alot has happened since
1.0.1. 
You need to log in before you can comment on or make changes to this bug.