88895 - FedEx shipping labels won't print

Status: VERIFIED DUPLICATE of bug 89151

(Core :: Printing: Output, defect)

Description

[Mitch Green]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010702
BuildID:    2001070204

You need an account at FedEx to try this, but this build won't print FedEx
shipping labels generated online.  The shipping label correctly images in the
browser interface, but then don't print.

Reproducible: Always
Steps to Reproduce:
1. visit URL above
2. generate shipping label
3. print

Actual Results:  HTML page absent the shipping label graphic.

Expected Results:  HTML page w/ graphic.

Comment 1

[Mitch Green]

*** Bug 88896 has been marked as a duplicate of this bug. ***

Comment 2

[Matthias Versen [:Matti]]

Reporter: Is the label generated with a plugin (Java, acrobat) or it´s a normal
image (gif, jpeg) ?

If the label is generated with an applet, then this bug is a dupe of bug 27478.

Comment 3

[Mitch Green]

The shipping label is generated server-side and presented to user as a large
.gif graphic within a web page.

Comment 4

[Mitch Green]

Attachment: a sample .gif shipping label that won't print

Comment 5

[dcone (gone)]

The page prints minus the image.  I think this is an imagelib problem, I get an 
assert when its trying to load the image. Pavlov.. do you have any ideas on 
this.

Comment 6

[grega]

any progress on this?  Has not had a comment since july.  WE need to get this
fixed for 0.9.4 and we are running out of time.

Comment 7

[Roland Mainz]

I played around a little bit with this one (using the Xprint module). It looks
that nsRenderingContextXlib::Draw[Scaled|%]Image() never gets called for that
GIF thing while printing - even if I embed it into a HTML page (layout calls
DrawScaledImage() in
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsImageFrame.cpp#1022).
Something in the crossplatform image printing code is broken... ;-(

Disabling both mem&disk cache does not help either.

The original example
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40949) is a 1bit GIF
image - but converting it to a 8bit GIF image did not help either (I used
Solaris sdtimage).
Converting it to a JPEG image helps... however the quality is bad in that case.
Just wondering... would converting the GIF to 1bit PNG image help in this case ?

Comment 8

[Mitch Green]

FedEx's web site allows the user to fill out a form, and it returns this graphic
as part of a new page.  Mozilla needs to correctly print the resulting page
without requiring the user do anything other than press the Print button in the
browser chrome.

Having the user save, convert and print a graphic file won't work.

Thanks,

Comment 9

[Roland Mainz]

> Having the user save, convert and print a graphic file won't work.

I know that. But it would be usefull info to figure out whether only GIF images
are affected or if this applies to PNG images of the same size and depth, too.
This would make locating of the issue much easier...

Comment 10

[Stuart Parmenter]

Back to printing.  The problem with printing this image is that the print 
document's loadgroup has nsIRequest::VALIDATE_ALWAYS set on it.  This causes 
imagelib to go refetch the image.  This causes the "printing is a race-
condition" effect to manifest itself.  Since the image being requested has to 
be refected from the network, and printing doesn't wait for the loadgroup to 
finish, printing happens before the image finishes loading.

I don't know why this only happens on this image, but if you turn off the 
memory cache, you won't get any images printing, which will show the race-
condition effect.

Comment 11

[Jaime Rodriguez, Jr.]

Grega - Pls work with nisheeth and team to work this one out.

--> rods

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

There used to be (not sure if fixed, I am unable to testright now) a bug that
you could not print MapQuest maps either. When you fix this, please check that
as well.

Comment 13

[sujay]

89151 is the maps bug

Comment 14

[Jussi-Pekka Mantere]

Shouldn't this be marked a dupe of Bug 89151 (with keyword added to that bug)?
Other dupes in 89151 refer to non-map dynamic content as well.

Comment 15

[Kevin McCluskey (gone)]

*** This bug has been marked as a duplicate of 89151 ***

Comment 16

[sujay]

verified.