Bug 50630 – REGRESSION (r73340-73429?): A label is printed blank at fedex.com

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Printing

[Sveto]

Created attachment 75815 [details]
Fedex label in PDF

I print extensively Fedex labels created from the web interfaces of Fedex.com. As of build 73429, once the label (a mixture of text and images) has been generated and the standard Safari printing dialog pops up, there is a blank page in the preview and it generates a blank page being on a paper, or saved as a PDF. Returning to the previous build solves the problem. I imagine printing will be broken for more things, however I can not test it further since that bug breaks completely my working flow. To elaborate further on the subject, Fedex uses standard javaScript to assemble the labels which as said contain images combined with text. No plugins are required to create a label and it works on all browsers (Safari, Opera,Firefox, IE). Also NO flash is being used for generating/displaying the labels. I'm attaching a label saved in pdf, generated with the previous working build.

[Alexey Proskuryakov]

Could you please provide step by step instructions to reproduce this bug?

From the regression range, one can't help but wonder if the fix for bug 50502 broke this.

[Sveto]

Reproducing the bug is very easy. Once the label is ready, or probably any other text/image combination you invoke the printing dialog. In the small preview one usually can see what is being printed, instead in the case with the broken build the preview shows a white (blank) window, and if one further proceeds to create a PDF file (instead of printing on a piece of paper for example), than the resulting file will be also blank compared to the attachment here.

[Pavel Feldman]

(In reply to comment #2)
> Reproducing the bug is very easy. Once the label is ready, or probably any other text/image combination you invoke the printing dialog. In the small preview one usually can see what is being printed, instead in the case with the broken build the preview shows a white (blank) window, and if one further proceeds to create a PDF file (instead of printing on a piece of paper for example), than the resulting file will be also blank compared to the attachment here.

Could you confirm that it still fails on nightly? I don't have Fedex labels to print...

[Sveto]

Created attachment 76081 [details]
Source of Fedex page with the created label

[Sveto]

Created attachment 76084 [details]
Picture of the generated label before printing

[Sveto]

Created attachment 76086 [details]
Picture of the label at the moment of printing

[Sveto]

I just tested with r73490 and yes the problem persists. I tested also with another page where I generate labels for Fedex and UPS. The page is ftd.com and although the coding there is very IE oriented and plays very ugly with Safari, I was able to reproduce the same error. It seems that it only happens when the page offers a "Print" button, which uses instructions that do not pass the data further to the printing system, however having the label displayed and trying with the proper printing system of Webkit also goes blank. If I try to print normal pages all seems to work ok, so that makes nailing down the bug more difficult. One thing is for sure, it works in all browsers and it works in webkit r73429 and prior. The 2 new builds after that broke the functionality.
I'm attaching here the source code of the page where Fedex generates the label and also a printout from Grab before I try to print and after I try so you have a better idea of the problem. In the source code I see a variable 
var labelImageSrc = "/shipping/labelAction.handle?method=doGetLabelFromCache";
which might have something to do with the problem. Also another strange thing is the iframe wants to load an empty html file.
 Please study the source code and let me know if I can be of further assistance.

[Sveto]

Created attachment 76087 [details]
Pic of Element Inspector over the "Print" button

[Sveto]

Sorry guys, just tested r73886 and the bug persists without a change. Please fix it since I won't be able to keep testing future builds. I'm stuck at r73340
I have attached here the source code of the Fedex page and print outs to illustrate the issue. I don't know what else can I provide to facilitate you. The new Webkit builds are the only once that fail, all other browsers are working good, that must tell you something.

[Alexey Proskuryakov]

Could you please double check that r73429 was the very first nightly that had this problem?

You can download old nighties from <http://nightly.webkit.org/>, and run them directly from a mounted disk image, without installation.

[Alexey Proskuryakov]

<rdar://problem/8768070>

[Pavel Feldman]

(In reply to comment #11)
> <rdar://problem/8768070>

My suspect is http://trac.webkit.org/changeset/73385. See http://trac.webkit.org/changeset/73385#file202- numbers for printing changed a lot. And the change is big :)

[Alexey Proskuryakov]

See also: bug 50970!

[Dave Hyatt]

This might be fixed by 50970.  We'll just have to see, since I don't have any clear steps to reproduce.

[Sveto]

I tested today again the latest builds. Starting with r73429 all the 3 newest once suffer from the bug. The last working build (which I keep using daily) is r73340
I tried today to get a testing account with Fedex, so you guys can experience it first hand, but ended with nothing. Fedex is extremely uncooperative. The only thing I can add to the data above is a view at the moment of printing the label with the last working build, so you can compare with what I already attached here. Well you guys have the source code too, surely someone can read though it and get an idea of where the printing system fails after the latest changes.

[Sveto]

Created attachment 76680 [details]
Picture at printing stage (the correct way with r73340)

[Alexey Proskuryakov]

Thank you for testing the historic nightlies!

Per comment 14, there is a decent chance that this is fixed in r74063 - but that revision isn't in the nightlies yet at the moment.

[Sveto]

Tested r74228 it has no fix, with this webkit takes the crown as being the only browser out there that has such a bug with a likely zero hope of getting it fixed in the near future. It is sad since later you will guaranteed introduce it to the next Safari update.

[Sveto]

You guys have really messed something fundamental in printing starting r73429 
I just tested version 3.1.2 of Safari on another computer and everything works like a charm with Fedex.

[Sveto]

Ok, guys. Thank you for the effort. As of build r75294 this bug has been fixed. Keep up the excellent work.

[Alexey Proskuryakov]

Per the above comment, fixed some time between r74228 and r75294.