User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce: Opened a badge from our application in the PDF viewer. Badge shows perfectly in the view. Actual results: Print to Dymo 450 label printer and the left side of the badge (as you look at the badge) is cut off. Expected results: Badge should have print exactly as rendered in the PDF viewer. This worked perfectly until upgrading to v62. I have done regression testing back to 61.02 and prints perfectly. This is affecting several of our clients who are using our system. I have attached 2 files to show the print before v62 and print after v62.

Do you have the same issue if you print it as pdf or XPS or to another printer ? Is it possible that you attach a demo PDF from your application to do a regression range search ?

Good morning. The badge prints perfectly as a PDF from Adobe Reader or from any other browser. It seems that I have isolated it to FF v62 only

chris: We need a testcase (an example PDF) and we need to know if this happens only with such a label printer (do i need such a printer to reproduce the bug) or this bug is not actionable.

I have attached a badge example you can play with. I just did a test. 1. opened the badge in the v62.02 PDF viewer and printed to copier. The "V" in "Visitor" is cut off. 2. open the badge in Chrome viewer and adobe reader, print and badge prints complete as expected. So,yes, if you print to any printer using your pdf viewer it appears you will see the same result. Thanks! - Chris

Thank you for the testcase chris. I can confirm a regression when you print the testcase on windows. The bug isn't visible if you print to pdf or to xps but I can see it when printing to my samsung laser printer. 1 tree died to generate the paper for my regression test :-) 2018-09-24T15:11:30: DEBUG : Found commit message: Bug 221706 - Use unwritable region when printing on Windows. r=jimm Read more information from the printing device to setup the unwritable region. Translate the printing context's coordinate system so that the point (0,0) refers to the top-left of the physical paper instead of the top-left of the printable region. MozReview-Commit-ID: 9ei2FgEUDyO

So, new regression, thanks

I was also able to reproduce with a real printer, though I'm not positive this is the exact same issue as the label maker. The PDF itself is 3.61in x 2.19in and has no margin on the left side. When Firefox prints this PDF to an 8.5in x 11in piece of paper the PDF gets aligned to the top-left corner of the paper and the top-left part of the PDF ends up in the unwriteable region of the printer. Usually this isn't an issue because the PDF will have a margin to account for this. With Acrobat and Chrome this doesn't appear to be an issue because when the PDF size and paper size differ they default to scaling/moving the PDF into the writeable region of the paper. It's worth noting, I can reproduce Firefox's behavior in Acrobat if I choose the "Actual Size" option under "Paper Size & Handling" in the print dialog. Chris, I'm still looking into a solution on our end, but it will probably take some time. On your side, if you're able to control generation of the PDF you could probably fix it by making the PDF size match the label paper size and adding in a margin around the badge.

Was there something done between FF v61 and v62 to change the print behavior in your viewer? v61 and before all work fine. I will give your feedback to the developers and see what they can see in the code for the badge setup. Thanks for diving into this. We have tons of clients using your browser and seeing this so, trying to find a solution! Thanks - Chris

(In reply to chris.livesay from comment #9) > Was there something done between FF v61 and v62 to change the print behavior > in your viewer? v61 and before all work fine. Yes, over in bug 221706 I changed Firefox to allow print output to extend into the unwriteable region (the area near the edge that printers can't cover). This fixed a lot of issues we were having where someone would print an 8.5x11 paper, but it would get shrunken down because of the unwriteable region. Somewhat ironically that bug fix printing output for another label company, so I can't simply revert the change.

Mike, does this update mean this will not be addressed and that we have to look for other solutions? status-firefox62: affected → wontfix Thanks - Chris

Brendan, I understand that the revert isn't an option but are you going to try to fix the issue? Chris, this mean that we won't fix that in a dot release of 62 but that we might fix that in 63 if we find a bug by then.

(In reply to Sylvestre Ledru [:sylvestre] from comment #12) > Brendan, I understand that the revert isn't an option but are you going to > try to fix the issue? So far none of the solutions I have are simple or easily upliftable, but I'm going to spend some more time on it today and see what I can come up with.

> Mike, does this update mean this will not be addressed and that we have to look for other solutions? No, it just means this isn't going to be fixed in a dot release for 62 release, but hopefully soon in future versions (like Sylvestre mentioned).

I saw that v63 is out. I tested and the same issue is still there. Any insight? Thanks

Too late to fix in 64. Marking this issue as fix-optional for 65; if you land a patch in nightly and think it's low-risk for beta, please request uplift.