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

Status: VERIFIED WORKSFORME

(Core :: Printing: Output, defect, P3)

Description

[Marc Attinasi]

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).

Comment 1

[Marc Attinasi]

Attachment: MapQuest page: prints OK from local file... isn't that special?

Comment 2

[Marc Attinasi]

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...

Comment 3

[Marc Attinasi]

Updated summary since it appears the page is printing, just very slowly.

Comment 4

[sujay]

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

[sujay]

target milestone?

Comment 6

[Marc Attinasi]

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.

Comment 7

[sujay]

still happening in 11/7 builds.

Comment 8

[rods (gone)]

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.

Comment 9

[sujay]

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

[rods (gone)]

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

Comment 11

[Asa Dotzler [:asa]]

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)

Comment 12

[Asa Dotzler [:asa]]

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

Comment 13

[Stuart Parmenter]

don?  is this still the case with the current image stuff?

Comment 14

[sujay]

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

[dcone (gone)]

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.

Comment 16

[sujay]

v

Comment 17

[Andreas Lange]

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

Comment 18

[malcolm]

This bug still referenced in release notes for 1.2b

Comment 19

[Bill Welch]

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

[Andreas Lange]

Regarding comment 19:
After the imminent 1.2-release, try that version - quite alot has happened since
1.0.1.