1685670 - Garbled PDF when printing if font-loading-api is disabled (via about:config layout.css.font-loading-api.enabled = false)

Status: NEW

(Core :: Printing: Output, defect)

Description

[info]

Attachment: Bildschirmfoto_2021-01-08_10-37-47.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Precondition:
In about:config, for security reasons, the option layout.css.font-loading-api.enabled is false.

Test environment:

• Debian or Windows with FF 78LTS (78.6.1), but also in current version (84.0.2)
• various PDFs but not all, e.g. https://www.tu-chemnitz.de/verwaltung/studentenamt/abt11/ordnungen/2020/AB_2020_27_2.pdf

Steps to reproduce:
1.) Open the PDF file in the browser
2.) wait 30sec (at first view document is displayed correctly)
3.) Print preview of PDF via hamburger button->Print... open

Actual results:

Some (or all) of the text is garbled (see attached file).

Expected results:

correct preview and printout

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Daniel Holbert [:dholbert]]

I was able to reproduce twice on Ubuntu, using a fresh profile (with layout.css.font-loading-api.enabled set to false, per STR).

jfkthame, do you know what might be going on here? The fact that the 30-second delay makes a difference seems particularly odd/interesting.

Comment 3

[Jonathan Kew [:jfkthame]]

I think the need for the 30-second delay to reproduce this is related to the gfxFontCache expiration timeout: font instances get "aged out" of the cache after not being used for 30 seconds.

Without knowing details of the pdf.js code, what I guess happens is that it extracts embedded font resources from the PDF and constructs @font-face rules with the resources as data: URLs, which works to display the document in the browser even if the font loading API is disabled.

But when we render the print preview (or the actual printed document, presumably), if the PDF's webfonts have expired from cache and need to be reloaded, we fail to wait for them to load (which would be detected via the font loading API) before rendering the document.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

In about:config, for security reasons, the option layout.css.font-loading-api.enabled is false.

Curious, what security reasons? If it's just about security hardening, the font loading API seems like an odd place to start.

In any case, we have this code to clone the non-rule font-face objects for static documents, and this pdf.js-specific code to deal with fonts.add() while printing, not 100% sure what that's about, it comes from bug 1524640. I wonder if this happens when:

• printing non-PDF pages which use @font-face and are static or such (I'm hoping we don't mess those up).
• PDF.js uses mozPrintCallback and a canvas element. I wonder if a reduced test-case could be created for loading a font with @font-face and using canvas after 30s, and whether it'd reproduce the issue.

Simplest fix is probably giving privileged access to the font-loading API to PDF.js (should be trivial-ish using the same nsContentUtils::IsPDFJs function to guard the access to the API). But I also wonder whether there's any reason to keep the font-loading-api.enabled flag around... We're not likely to disable it any time soon...

Comment 5

[Emily McDonough [:alaskanemily]]

jfkthame: Do we expect this to be fixed by 1690235?

Comment 6

[Jonathan Kew [:jfkthame]]

I think this is a separate issue. For one thing, bug 1690235 is Mac-specific.