1671288 - Amazon shipping labels print blank intermittently

Status: RESOLVED WORKSFORME

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

Description

[Sean Voisen (:svoisen)]

A bug reported internally in Slack by vchin: Unable to print Amazon return shipping labels from both Nightly (83) and, later, release (81):

There seems to be an issue printing Amazon return address labels using the new print UI. The preview looks correct but the address label and the barcode does not print out. I just tried to print using release and it works fine but it doesn’t print correctly in Nightly (same issue with the UI and the system dialog).

After trying again, user couldn't get it to print in release either. Then performed the folllowing:

I shut down Firefox release, restarted using the same profile, and printed again. And ta da, it prints fine.

I have access to a sample label (protected for privacy). The printed output is missing both of the <img> elements that are used for the label and barcode (Amazon's labels are not PDF). But all of the other content is printed. Images are inline. Label is a data URI and the barcode is not.

Comment 1

[Sean Voisen (:svoisen)]

Attachment: Broken print output

Comment 2

[Sean Voisen (:svoisen)]

I'm unable to reproduce locally on macOS, Nightly 83 using an HP printer with either the old or new UI.

Given source of the report I'm going to keep this private to MoCo employees for now (because of the attached printout photo, but maybe there's nothing too confidential in there).

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Sean Voisen (:svoisen) from comment #0)

A bug reported internally in Slack by vchin: Unable to print Amazon return shipping labels

Vicki, any chance you still have the ability to test this & can confirm whether it still reproduces?

Sean mentioned that he had a testcase, but he's no longer at Mozilla, so I'm not sure if this is actionable at this point unless you have a testcase and/or can confirm whether it still happens.

Comment 4

[Daniel Holbert [:dholbert]]

Closing this as INCOMPLETE for now; hopefully we've fixed this over the past year. Or if not, we need confirmation that it still happens and some steps and/or a testcase.

Comment 5

[Julien Chaupitre]

Attachment: Centre de retours en ligne_firefox.pdf

Print to PDF of this page in Firefox

Comment 6

[Julien Chaupitre]

Attachment: Centre de retours en ligne-edge.pdf

Print to PDF of this page in Edge.

Comment 7

[Julien Chaupitre]

I'm reopening this bug because my wife experienced this issue today with Firefox 92.0.1 (see PDF attached).

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Is there any chance you could attach the HTML (as in "save as") that generated that PDF? Thanks!

Comment 9

[Julien Chaupitre]

I can no longer reproduce this behavior, which is super strange - will keep trying

Comment 10

[Romain Testard [:RT]]

I also cannot reproduce on release

Comment 11

[Frank Griffith Jr]

Included in Jira S&Q22 Epic https://mozilla-hub.atlassian.net/browse/FFXP-1762 for traceability.

Comment 12

[Frank Griffith Jr]

Can we verify if this is still an issue? Also clarify "barcode" vs. "QR code"? We have closed a similar issue based on the QR code (https://bugzilla.mozilla.org/show_bug.cgi?id=1747724) as the output was "as designed" by Amazon.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Frank Griffith Jr from comment #12)

Can we verify if this is still an issue?

This was still an issue as of 4 months ago, per comment 5.

For future reference for myself & anyone else testing this: it looks like I can test this (for free, I think?) by initiating an Amazon return, choosing "purchased by mistake", and choosing "UPS Dropoff Point" as the method-of-return (to get a shipping label). Supposedly that will cost me $5.99 (which is paid via being deducted from my refund), but it'll presumably be free since I'm not actually returning anything. (I just picked a random recent Amazon purchase as the thing-to-be returned, which I don't actually intend to return.)

I ended up with a printable page that looks very-similar in structure to the first attachment here, except I'm not getting any missing content.

I'll save a copy of the webpage for future reference/analysis, though I probably won't post it here, to protect personal info. But a few quick observations:

• The empty barcode-areas in the first attachment here are just <img> elements -- they're not iframes or anything fancy like that. The top one has src="/documents/download/[UUID]/ShipperLabel" (for some [UUID]) , and the lower one has src="https://trans-rmabarcode-images-na.s3.amazonaws.com/[filename].gif?[bunch-of-params]" (for some [filename] random string of numbers and letters, and with a bunch of params after the ? as shown)
• When I load the page locally, those images do "blink into view" shortly after the rest of the page loads.
• So: I wonder if this is/was just a case where the images happen to be slightly slow-to-load, and we don't find them in the cache when we show print-preview, and we fail to have them ready for some reason? [I tried to trigger this manually by imposing network throttling in our network devtools and checking the "disable cache" checkbox, and then doing Ctrl+P before the images had shown up in the page -- but we ended up doing The Right Thing in this case, which is that print-preview made me wait with a loading throbber-image, and when it finally rendered, the images were there.)

Also clarify "barcode" vs. "QR code"? We have closed a similar issue based on the QR code

(As shown in screenshots here, this is about more-traditional barcodes [not QR codes] which indeed are supposed to print.)

Given that I was able to test this (i.e. arrive at the originally-photographed printable UI) and I couldn't reproduce with repeated testing and network-throttling, and we haven't had reports in 4 months (and even then it was only a one-off and then couldn't be reproduced after that), I'm going to tentatively close this as WORKSFORME. Please reopen if anyone can reproduce again, though.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: redacted screenshot of a successful printout

This bug had the moco-confidential flag (per comment 2) due to the screenshots containing personal information from the reporters.

Rather than leaving this flagged that way forever, I've marked those attachments themselves as private (only accessible to users with particular security flags), and I'll attach a redacted screenshot of what I personally see when printing my own aforementioned Amazon return label.

For comparison:

• Vicki's original printout-photo here (the original attachment) looks essentially just like this, except the "Return Mailing Label" and "Return Authorization Slip" areas are blank. (Those two img elements rendered blank for some reason.)
• Julien's Firefox printout also looks similar to this this, except in his case the "Return Authorization Slip" is present, and it's only the upper Mailing Label that's missing (and in his case, it seems to also be zero-sized for some reason). Also, his printout is in landscape mode and is in French.
• Julien's Microsoft Edge reference-printout looks similar to this (with the return label present), and is in portrait-mode (though the page-orientation probably doesn't matter -- I get working results from current Firefox regardless of portrait vs. landscape orientation)

Comment 15

[Daniel Holbert [:dholbert]]

Un-hiding per comment 14. In the event we get more/similar reports of this happening for users, this will make it easier to correlate/associate the bugs.