2050228 - When printing PDF from Nevada DMV, none of the text makes it into the printout; only the circular "seal" graphic is printed

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Yan R]

Attachment: TMP_PDF_Print_Preview.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0

Steps to reproduce:

This is a niche issue that I keep getting when printing PDFs generated by our Nevada's DMV system. It's been around since at least COVID days, so affects all recent Firefox releases.

I verified the issue is not printer related, as I sent the same file to various different printers with the same result (2 at my house and 2 at my work).

I can print this PDF without problems in Edge, Chrome, and Acrobat, using the same printers.

Other PDFs that I open in Firefox print without issue, so I do think the issue is related to the system that our state uses when creating these documents.

Actual results:

When printing, I only get the state seal printed on the page. The rest of the page is completely blank. None of the text or rectangular elements print.

Expected results:

The page should've printed as shown in print preview and as printed by other browsers / Acrobat.

Since the PDF contains sensitive information, I won't be able to attach the file itself to the ticket, so I'm attaching a sanitized screenshot.

Att:
TMP_PDF_Print_Preview.jpg - this is what's shown in Firefox & Print Preview
TMP_PDF_Printed_Result.jpg - what actually comes out of the printer

Comment 1

[Yan R]

Attachment: TMP_PDF_Printed_Result.jpg

Comment 2

[Yan R]

I have the PDF saved and can e-mail it to a specific developer, once one is assigned. I just don't want to leave it posted here in public view.

Comment 3

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[David Shin[:dshin]]

Hi, thanks for filing & detailed testing.
I wonder if it's related to bug 1994942 which seems related to another printing-related bug - Does this happen on Firefox 146?

Comment 6

[Yan R]

Hi David,

Thanks for taking a crack at this - much appreciated!

Yes, it was happening on older releases as well.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Yan R from comment #2)

I have the PDF saved and can e-mail it to a specific developer, once one is assigned. I just don't want to leave it posted here in public view.

Thanks for being willing to share, and I definitely understand not wanting to share publicly. I'm interested to take a look and will treat the PDF confidentially, if you could email it to me: [e-mail]

Thanks!

Comment 8

[Yan R]

<emailed the PDF privately>

Comment 9

[Daniel Holbert [:dholbert]]

Thanks -- received. So far haven't been able to reproduce in Firefox release or Nightly on Linux, but it could easily be a Windows-specific thing -- I'll try that next.

Comment 10

[Daniel Holbert [:dholbert]]

OK -- on Windows 11, I can reproduce in both Firefox release and Nightly, if I print to a real printer or the MS Print-to-PDF backend (the latter giving me a PDF with just the seal, as shown in comment 1).

If I instead use Firefox's built-in Save-to-PDF backend, then I get a PDF that looks fine. But if I then try to print that PDF to another print backend (real printer or MS-Print-to-PDF), then it still reproduces the problem.

I can't reproduce at all on Linux or macOS, though. So this seems to be Windows-specific.

This doesn't seem to be dependent on Skia vs. Cairo as our printing backend, because I can repro on both Nightly and release on Windows, and my Nightly there has print.experimental.skpdf set to true (default for Nightly), and that doesn't avoid the bug.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing possibly-related selection bug

One other interesting thing about this PDF -- on Linux at least, I don't hit the print bug, but I do hit another possibly-related bug. When I try to select text in the PDF, the selection area paints the wrong text -- text from further down the page.

See attached screenshot (just showing the "instructions" part of the PDF which is also shown in comment 0). I've selected the second half of the word "corner", but the highlight region should show "ner" but instead it shows 4-5 lines further down (part of the word "exempt").

Comment 12

[Daniel Holbert [:dholbert]]

Regression range for the main issue here (printout only producing the circular "seal" graphic):
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=fa3677b2a1e568a0831c7f0a1507cd9972bdd420&tochange=a72c2fe447612a537f9a5228618453ffa6e55ca3

In that range, I'm guessing this was a regression from either:

• Bug 1721127 - Apply win32 printing surface fix [...]
  (this one seems most-likely given it windows-specific)
• ...or one of the patches for bug 1722300, which were a handful of cairo updates.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #12)

In that range, I'm guessing this was a regression from either:

• Bug 1721127 - Apply win32 printing surface fix [...]

This one still seems to back out cleanly (whereas the commits from bug 1722300 do not). So I kicked off a try run with this one backed out, just to see if it makes a difference, and I'll give it a try with the reporter's privately-shared testcase once the build is done:
https://treeherder.mozilla.org/jobs?repo=try&revision=09d92b6c946a45c63c2577ac8c766fe90a033a13

Comment 14

[Daniel Holbert [:dholbert]]

Nope, that Try run (backing out Bug 1721127) still reproduces the bug. So, that probably wasn't the culprit; and it seems most-likely this was a regression from bug 1722300.

Comment 15

[BugBot [:suhaib / :marco]]

:jfkthame, since you are the author of the regressor, bug 1722300, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 16

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1722300

Comment 17

[Jonathan Kew [:jfkthame]]

Yan R, could you please also share one of the problematic PDF files with me (email: [e-mail]) for further investigation? I will of course treat it as private, not to be shared further. Thanks!

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #10)

This doesn't seem to be dependent on Skia vs. Cairo as our printing backend, because I can repro on both Nightly and release on Windows, and my Nightly there has print.experimental.skpdf set to true (default for Nightly), and that doesn't avoid the bug.

That makes sense -- this looks like a failure in the cairo win32 print backend, which is still how we print to "real" printers on Windows (including the MS print-to-pdf destination, as that's also a win32 printer driver). The skpdf pref only switches our built-in Save To PDF code path to use skia, not other print operations.

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew [:jfkthame] from comment #17)

Yan R, could you please also share one of the problematic PDF files with me (email: [e-mail]) for further investigation? I will of course treat it as private, not to be shared further. Thanks!

I've now forwarded the PDF to you (sorry, I probably should have done so sooner, after reaching the limits of my own initial investigation).

Comment 20

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2050228 - Guard against dash length becoming zero in cairo-win32 printing backend. r=#gfx-reviewers

Comment 21

[Jonathan Kew [:jfkthame]]

It fails because the PDF includes a couple of lines (where the user is expected to "cut or fold") that are specified as dashed, but with such a minuscule dash length that the dashing is invisible on any reasonable output device (and on screen they look solid even when zooming way in). In the cairo-win32 printing backend, the dash specification gets scaled and converted to integer logical units, and the lengths collapse to zero. That result in the GDI function ExtCreatePen failing, which then sets an error status on the cairo surface, and no further drawing happens.

To avoid this, we can enforce a min dash (or gap) length of 1 logical pixel. This shouldn't be visually significant (it'll still be barely noticeable, depending on device resolution), but will avoid the GDI failure.

Comment 22

[Jonathan Kew [:jfkthame]]

When "printing" via the MS Print-to-PDF driver, this results in a line where the dashing does start to become (barely/erratically) visible in Adobe Reader once I zoom in to 600% (on a 96dpi screen; slightly less zoom is sufficient on a higher-res display). So it's theoretically a slight visual corruption compared to the original, which would require a zoom %age in the thousands to make the dashing visible, but not in a significant way.

Comment 23

[Jonathan Kew [:jfkthame]]

Looking back at the regression range, I'm pretty confident this was actually a result of bug 1721127. Prior to the fix there, the win32 surface was failing and falling back to rendering the entire doc as a rasterized image. Once that was fixed, then we are actually drawing through GDI, and we run into the ExtCreatePen failure.

Backing out bug 1721127 (comment 14) didn't help because other cairo updates in the interim mean we no longer run into the original win32 surface failure, and so this problem persists.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5999dca9bc0f
https://hg.mozilla.org/integration/autoland/rev/f02362fbd315
Guard against dash length becoming zero in cairo-win32 printing backend. r=gfx-reviewers,lsalzman

Comment 25

[rperta]

https://hg.mozilla.org/mozilla-central/rev/f02362fbd315

Comment 26

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected, along with ESR.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox154 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

Comment 27

[Jonathan Kew [:jfkthame]]

The failure mode here is presumably rare, but given how completely it fails (being unable to print a document could be pretty frustrating!) and how small/simple the patch is, I think this is worth an uplift.

Comment 28

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2050228 - Guard against dash length becoming zero in cairo-win32 printing backend.

Original Revision: https://phabricator.services.mozilla.com/D315345

Comment 29

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Certain documents fail to print on Windows
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial patch to avoid zero-length dash specifications that cause GDI errors
• String changes made/needed?: none
• Is Android affected?: no

Comment 30

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined/Reason for urgency: Certain documents fail to print on Windows
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial patch to avoid zero-length dash specifications that cause GDI errors
• String changes made/needed?: none
• Is Android affected?: no

Comment 31

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2050228 - Guard against dash length becoming zero in cairo-win32 printing backend.

Original Revision: https://phabricator.services.mozilla.com/D315345

Comment 32

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2050228 - Guard against dash length becoming zero in cairo-win32 printing backend.

Original Revision: https://phabricator.services.mozilla.com/D315345

Comment 33

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined/Reason for urgency: Certain documents fail to print on Windows
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial patch to avoid zero-length dash specifications that cause GDI errors
• String changes made/needed?: none
• Is Android affected?: no

Comment 34

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: Certain documents fail to print on Windows
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial patch to avoid zero-length dash specifications that cause GDI errors
• String changes made/needed?: none
• Is Android affected?: no

Comment 35

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2050228 - Guard against dash length becoming zero in cairo-win32 printing backend.

Original Revision: https://phabricator.services.mozilla.com/D315345

Comment 36

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/9e855e69d97a
https://hg.mozilla.org/releases/mozilla-beta/rev/f90efce3a43d

Comment 37

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr153/rev/a6e9e09ec429

Comment 38

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/020331437488

Comment 39

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/6e6f60bd844d