Closed Bug 1854090 Opened 2 years ago Closed 2 years ago

In PDFs: characters are wrongly mapped when document uses a non-embedded font not present in the system

Categories

(Firefox :: PDF Viewer, defect, P3)

Firefox 117
defect

Tracking

()

RESOLVED FIXED
121 Branch
Tracking Status
firefox-esr115 --- fixed
firefox119 --- wontfix
firefox120 --- fixed
firefox121 --- fixed

People

(Reporter: seb, Assigned: jfkthame)

References

(Regression)

Details

(Keywords: regression)

Attachments

(11 files, 1 obsolete file)

Attached file 392060454_copy.pdf

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

Steps to reproduce:

Drag the attached PDF into 117.0.1 Firefox to display with the internal PDF view.

Actual results:

All the text is completely garbled showing all non-ASCII characters.

If I set config browser.display.use_document_fonts=0 then it renders the text ok.

The same is seen with all PDFs from this same source.

The problem wasn't noticed with older versions of Firefox (it's only recently started).

Expected results:

Other PDF readers including Chrome browser all render the attached PDF just fine.

Additional info:
OS is 64bit Windows 10

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

Component: Untriaged → PDF Viewer

I tried to reproduce this issue on Firefox 117.0.1 (20230912013654) using Win 10, but with no success. The attached PDF file is displayed correctly with its content eligible. Are there any additional steps (settings) or something that I'm missing?
Thank you!

Flags: needinfo?(seb)
See Also: → 1563678

Since a "See Also" has been added, note that bug 1563678 is an opposite bug: rendering fails when browser.display.use_document_fonts=0.

BTW, under Linux, I cannot see any issue with the attached PDF file, whether browser.display.use_document_fonts is 1 or 0.

Attached file Another example PDF

Another example - different PDF but same problem.

This is what the PDF looks like in Firefox

I have attached another PDF which also has the same problem, plus a screenshot of how it looks.

The 2 PDFs have different Application & PDF Product tags (i.e. they were produced by different software).
They also have different PDF Versions "1.4 (Acrobat 5.x)" vs "1.5 (Acrobat 6.x)"

What they have in common is they both use Helvetica font (with Ansi encoding) which is not present on my system. When I view in Acrobat, it substitutes "ArialMT" as the actual font and displays fine. In Firefox whatever the substitute font is, clearing the character codes are not mapped correctly.

Flags: needinfo?(seb)

Could you open the devtools (ctrl+shift+K) and copy-paste what you've in the console ?
Could you copy-paste your config from about:support ?

In the console:

Partitioned cookie or storage access was provided to “file:///C:/Users/seb/Desktop/DL/Proof%20of%20Delivery%20782253704390.pdf” because it is loaded in the third-party context and dynamic state partitioning is enabled.
Warning: Invalid absolute docBaseUrl: "file:///C:/Users/seb/Desktop/DL/Proof%20of%20Delivery%20782253704390.pdf". pdf.worker.js:973:13
PDF 55bc93cebc3f3f9306afdb503f711856 [1.5 iText 2.1.2 (by lowagie.com) / -] (PDF.js: 3.9.146 [48cc67f17]) viewer.js:1530:13

Attached file Config from about:support (obsolete) —
Attachment #9354355 - Attachment is obsolete: true

There is nothing strange here except font.internaluseonly.changed: true but there's nothing on searchfox about this pref.
We're probably fallbacking on a font which is not what we expected.

Just to be sure, I tried it with font.internaluseonly.changed: false and with font.internaluseonly.changed deleted, and still the same.

browser.display.use_document_fonts=0 fixes the PDF, but then every web page has the wrong fonts.

If I use the Inspector to view the corrupt PDF, the texts are correct within the DOM HTML itself. Computed font-family shows as sans-serif. From the Fonts tab, the actual fonts used are Arial and Segoe UI (not sure how to tell where each one is used, but I guess for sans-serif family it will be Arial).

Actually, forget that last bit about the DOM HTML - I see now that the visibly document text is rendered in a canvas element.

Summary: Some PDFs have garbled fonts → In PDFs: characters are wrongly mapped when document uses a non-embedded font not present in the system

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

For more information, please visit BugBot documentation.

Flags: needinfo?(cdenizet)
Severity: -- → S3
Flags: needinfo?(cdenizet)
Priority: -- → P3

I'm not very familiar with how the Severity levels are decided, but going by the descriptions here I would personally suggest it may be S2, since the workaround is not very satisfactory - setting config browser.display.use_document_fonts=0 changes the fonts on every website viewed, not just within PDF docs.

One further piece of information which may be helpful:
The problem has only started recently - I work with these PDFs all the time and didn't notice the problem before Firefox 117.
The problem also shows up in a web-app which uses pdf.js, and again only started with Firefox 117, even though the pdf.js version hadn't been updated recently.

So the problem seems to be related to something deeper in the Firefox architecture rather than being within pdf.js which I believe is used as the rendering engine.

I agree that the workaround isn't crazy but you just picked up a part of the full sentence:

(Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist 

That said, S3 doesn't mean that we don't care about it but just that it isn't a priority for now.
And to be clear, maybe the bug is because of some changes in pdf.js/Firefox or some changes in pdf.js/Firefox highlight a problem with your own setup.
In considering, that I can't reproduce it myself and QA neither, I'm inclined to think that we're in the second case.
I'll try to figure out a way to know what's the font you're really using when the text is drawn on the canvas.
Could you try to use mozregression to figure out which patch has introduced this issue ?

Thanks for your reply and the clarification.
mozregression is a useful tool :)

I've also now discovered something else about the bug: it only occurs once Firefox has been launched for at least a minute or so. At first I ran through all builds in mozregression without seeing the problem. Then I tried a fresh profile of my installed Firefox and couldn't get the problem either. Then I went back to my normal profile and again couldn't see the problem.

It turns out that you have to wait approx 1 minute and a few seconds after launching firefox for the PDF to show corrupted. For the first minute it loads fine. It's not to do with the number of times the document is reloaded, or related to anything else running. It just needs approx 1 minute on my system before the bug appears. Is there some process where Firefox preloads and caches common system fonts perhaps?

Anyway now I know to wait 1min+ before testing, I was able to pinpoint the regression using mozregression ...

2023-10-04T20:13:20.892000: DEBUG : Found commit message:
Bug 1832514 - Update PDF.js to new version d520754bcf32990259503682956bc24399c6bc76 r=pdfjs-reviewers,marco
Differential Revision: https://phabricator.services.mozilla.com/D177736

Full log attached below.

Keywords: regression
Regressed by: 1832514

I have the same issue, it started a few days ago.
I work with PDFs in Firefox almost daily, never seen this before.
My impression was that it started with one of the latest Firefox updates.
Current version: 118.0.2 (64-bit) on Windows 11.

See PDF test file and result in Firefox PDF viewer here: https://github.com/mozilla/pdf.js/issues/17109#issue-1937156297

Added a reference to Bug 1857015 which seems to be a duplicate of this one.

Duplicate of this bug: 1857015
Attached image image.png

I added some code to help to debug this issue so in order to get some info, please follow this:

  • download the very last firefox nightly (120 with buildid 20231011092203)
  • in about:config, set the pref pdfjs.pdfBugEnabled to true,
  • append #pdfBug=all&textLayer=visible to the pdf url and reload

Now you should see in green the text as it is on the canvas and in black the text as it is in the text layer.
Could you screenshot some green garbled text ?

Then right click on the green garbled text you chose previously, right click and Inspect, devtools should open.

Then click on garbled text and in the pdf debugger (panel on the right) you should see a check mark close to the internal font name and the font we're trying to substitute (likely something like g_d0_sf6 for the internal name and Arial for the font name as it is in the pdf), click on log and then copy/paste the what you have in the console.
In the devtools you should have a panel called Fonts (on the right on my screenshot) , and under g_d0_sf6 you should have the name of the font which is really used to render: could you share it here ?

OK, I can do that but will need some help:

  1. Where do I find "last firefox nightly (120 with buildid 20231011092203)", and install instructions?
  2. How do I insert screenshots from clipboard here? (First time I'm on Bugzilla)

OK, I found and installed last Firefox nightly.

No idea about build ID, this is what I find under Help / About Nightly:
120.0a1 (2023-10-11) (64-bit)

This file still renders incorrectly: https://s1.q4cdn.com/806093406/files/doc_downloads/test.pdf

  • In about:config, I have set set the pref pdfjs.pdfBugEnabled to true
  • Added #pdfBug=all&textLayer=visible to URL and reloaded. Text got green shadow.
  • I have no idea how to paste a screenshot or a jpg/png file here, but it renders identical to what I showed here: https://github.com/mozilla/pdf.js/issues/17109
  • I have opened devtools, but am unfamiliar with this tool.
  • When I click on the first line (correctly rendered), the font inspector indicates : " g_d0_sf4 baseFontName Arial"
  • When I click on the second line (incorrectly rendered), the font inspector indicates : " g_d0_sf6 baseFontName Arial"
  • I clicked "Log" next to "g_d0_sf6", and get this in Console:
    Object { css: "g_d0_sf6,sans-serif", guessFallback: false, loadedName: "g_d0_sf6", baseFontName: "Arial", src: "local(Arial),local(Helvetica),local(Helvetica Neue),local(Arial),local(Arial Nova),local(Liberation Sans),local(Arimo),local(Nimbus Sans),local(Nimbus Sans L),local(A030),local(TeX Gyre Heros),local(FreeSans),local(DejaVu Sans),local(Albany),local(Bitstream Vera Sans),local(Arial Unicode MS),local(Microsoft Sans Serif),local(Apple Symbols),local(Cantarell),url(resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf)", style: {…} }
  • In the Fonts panel I opened "All fonts on page" and find g_d0_sf6 at the bottom. The other fonts have a font name (e.g. g_d0_sf4: Arial Bold), and they are fine in the preview. On g_d0_sf6 it says instead: Z@RD450.tmp and the preview is garbled.

Hope this helps!

Attached image image.png

Sadly (or happily for me personally), I'm no longer able to reproduce the bug. Not with my current install (118.0.2) nor with the debug nightly build.

PDFs were broken yesterday but today no more. The only thing which changed on my system were some Windows updates.

This Z@RD450.tmp doesn't look nice.
Since the font isn't in the pdf we're trying to fallback on one of the font in this list:

local(Arial),local(Helvetica),local(Helvetica Neue),local(Arial),local(Arial Nova),local(Liberation Sans),local(Arimo),local(Nimbus Sans),local(Nimbus Sans L),local(A030),local(TeX Gyre Heros),local(FreeSans),local(DejaVu Sans),local(Albany),local(Bitstream Vera Sans),local(Arial Unicode MS),local(Microsoft Sans Serif),local(Apple Symbols),local(Cantarell),url(resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf)

According to:
https://community.adobe.com/t5/acrobat-reader-discussions/z-xxx-tmp-files-in-user-temp-folder-causes-gibberish-font-in-printout/td-p/9883829?profile.language=de
this font could be a leftover from Acrobat (the thread is a bit old so I don't know if it's still relevant).

:jfkthame, do you know if it's possible to avoid to load such a font ?

Flags: needinfo?(jfkthame)

I'm not sure what we can do about this...

As far as I can tell from reading the Adobe-community discussions, what I think is happening is that in some cases, Acrobat creates a "temporary" font file (as part of its printing process?) containing a font that is presumably a (subset, re-encoded) version of Helvetica or Arial, and makes it known to Windows (presumably so that the printer driver etc can use it). But they're doing this in such a way that it also appears in the system font collection that we get from the Windows (DirectWrite) APIs. So then, when we ask for Helvetica (or Arial, or whatever), we get this garbled font.

That's bad enough, because it would mean there's a risk of getting a garbled font if an application tries to use it while an Acrobat print job is happening; but worse, it also sounds like they sometimes fail to delete it when they're done. In which case the problem would be persistent.

Seb or egil.opsahl, can either of you check if there's a file named Z@RD450.tmp (or some similar naming -- it's probably a "unique" name generated on the fly, so the exact characters may vary) in your temp folder (probably at C:\Users\<user>\AppData\Local\Temp, I guess)? If so, I would be interested to see a copy. Maybe there's some way we can identify and block such fonts, even though Acrobat has made them "available".

Flags: needinfo?(seb)
Flags: needinfo?(jfkthame)
Flags: needinfo?(egil.opsahl)

I can't find any file named like this, but then the problem has now stopped on my system (seemingly since some Windows Updates installed today).

What I did notice before when I opened this test pdf in Adobe Acrobat Pro was that the font of the 2nd line (the one showing garbled in Firefox) was showing up in the font drop-down as something like Z@.... (when I went to edit the text).

Now that the problem has stopped on my system, when I go to edit this text in Adobe Acrobat Pro the font just shows as Arial.

Flags: needinfo?(seb)

I'm guessing that the Windows update process (or the reboot that it presumably forced) may have cleared out lingering temporary files. If the problem ever comes back for you, let's take another look.

Maybe egil.opsahl will have something we can examine....

  • I find a large number of Z@Rxxxx.tmp files in my c:\Users\<myself>\AppData\Local\Temp folder.
  • All files are timestamped in quite narrow time windows, on dates ranging from 18th Sep to 11th Oct (yesterday morning)
  • I generate PDF files from Office 365 applications, that has lately been Word and Powerpoint. I then generate PDFs using "File / Save as"
  • It very seldomly generate PDF files using Acrobat, I am 100% sure I did not do so yesterday.
  • So if Acrobat generated those files, it must have done so while opening PDF files.
  • I have opened PDF files in Acrobat today, and there are no Z@Rxxxx.tmp files timestamped today.
  • So maybe it is not Acrobat that generates the files.
  • There are ten (10) files with identical timestamp yesterday morning, the time coincides with the time period where I raised the issue first on Github.
  • I did not generate any PDF file yesterday morning.
  • This is one of those files timestamped yesterday morning (Z@RF2FE.tmp) : https://drive.google.com/file/d/1WqEBLoICOwiyB1AGvuuNUr8YxDHlkK_s/view?usp=drive_link
  • This is Z@RD450.tmp, which is in the same folder (timestamped 22nd Sep): https://drive.google.com/file/d/17mSlKbWFUCYDxCQIubWyGnypN911koYm/view?usp=drive_link
Flags: needinfo?(egil.opsahl)

:egil.opshal, could you attach a font to this bug (there is a button Attach New File in the Attachments section on the top of this page) ?

Flags: needinfo?(egil.opsahl)
Attached file Z@RD450.tmp

This is the file my PDF plugin tried to use.

Flags: needinfo?(egil.opsahl)

Did anyone get a chance to consider my input here?

I looked at the attached file, and confirmed that it is a TrueType font resource; looking into the name table (which provides the font's identification -- filenames are arbitrary, and renaming a file does not by itself affect the name of the font within it), we find:

  <name>
    <namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Z@RD450.tmp
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
      This is a unique ID
    </namerecord>
    <namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Z@RD450.tmp
    </namerecord>
    <namerecord nameID="5" platformID="1" platEncID="0" langID="0x0" unicode="True">
      1.0
    </namerecord>
    <namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Arial
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="0" langID="0x409">
      Z@RD450.tmp
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="0" langID="0x409">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="0" langID="0x409">
      This is a unique ID
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="0" langID="0x409">
      Z@RD450.tmp
    </namerecord>
    <namerecord nameID="5" platformID="3" platEncID="0" langID="0x409">
      1.0
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="0" langID="0x409">
      Arial
    </namerecord>
  </name>

Notice the name ID 6 here, which is the font's "PostScript name". It's "Arial". But this is not in fact a standard Arial font; it has been subsetted (probably) and re-encoded (certainly) such that the "character" repertoire it supports is completely non-standard.

What I am assuming has happened is that as part of Acrobat's printing process -- maybe related to a particular printer driver, even -- any embedded font resources in the PDF file are extracted into "temporary" files like this, and added to the current system font collection. I expect it does this so that the printer driver software -- as opposed to the Acrobat application itself which opened the PDF -- can use the font when printing.

But because the font's PostScript name -- which is supposed to be unique to the font resource -- is "Arial", when pdf.js uses a FontFace with src: local("Arial") to try and access the system's Arial font, it may get this re-encoded version instead of the standard one, because it has the same PS name. And that results in totally garbled display, because the encoding of this font doesn't match what the document assumes.

Given that Acrobat has given this font a random family name that ends with ".tmp" (and presumably that's the pattern it always uses), maybe we can use this as a clue to ignore any such fonts when looking up what's available on the system. It'd be a rather arbitrary heuristic, but perhaps usable as a workaround.

When several fonts have the same unique name, is it possible to set a precedence based on the directory they're found ?
For example, an Arial in \Windows\Fonts could have the precedence on one in \Users\Foo\AppData\Local\Temp folder.
Or maybe a .ttf, .otf, ... could have the precedence on a .tmp, wdyt ?

Maybe I misunderstand the explanations, but I fail to understand how Acrobat can be blamed.

Example:
My online accounting system generates PDF previews of invoices, where the word "DRAFT" (in Norwegian) is added as a large "watermark". When I preview this in Firefox, that word is garbled (and this started last week, I never had the issue before). I preview it with the Firefox built-in PDF viewer.

If I open the accounting system in Chrome, and do the same preview (with Chrome built-in PDF viewer), it renders correctly.

So for me the issue seems to be in the Firefox built-in PDF viewer, which (as far as I understand) has nothing to do with Acrobat?

:egil.opsahl, the Arial font in your pdf is not embedded hence we try to fallback on a font you've on your system. Every pdf render has a different strategy to choose the fallback font, it's why the rendering can be different from Chrome.
So a software (very likely Acrobat but it can be another one) has generated for whatever reason this font called Z@... and your system recognizes it like a "true" Arial because of what Jonathan mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c37.
So the problem isn't because of Firefox here (even if we can maybe try to workaround it) but because of an other software which is generating these fake Arial fonts and for any reasons isn't able to remove them after they've been used and because your pdf doesn't embed all its fonts.

:calixte

Thank you for your additional information and explanation.

So I did the following:

  • Closed all instances of Adobe Acrobat
  • Deleted all Z@Rxxxx.tmp files in my c:\Users\<myself>\AppData\Local\Temp folder

Result:

This it how it should look.

Could you follow the steps described in https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c23 and tell us what you have ?

Yes I know, but you said

Invoices from FedEx (like the one :Seb posted earlier in this thread) now shows no text in the sections that were previously garbled. Just blank spaces.

and consequently, I'd like to understand why you have no text when you should have one, or maybe I misunderstood something.

OK - sorry. I understand you want me to repeat that process with one of the documents that are rendered with blanked-out text.

So...

  • I opened the document in Firefox Nightly: It rendered correctly (!)
  • I checked again the preview in Firefox: Still blank spaces on that one out of of 3 such documents.
  • I opened a new instance of Firefox and opened the problematic document: It rendered correctly (!)

So it seems like deletion of the *.tmp files fixed the issue for me - but I was unable to see it because I kept trying in an instance of Firefox that has been open for a week or two. Starting a new instance of Firefox apparently did the trick.

-> Case closed maybe?

Note that on my system I found that Firefox had to be running for at least a minute or so before the problem would happen. Seems it takes this long to scan the fonts and cache them. The exact time probably varies from system to system, so try leaving Firefox running for a while to give it a change to scan and cache the 'bad' font.

And maybe run Acrobat in the mean time - if it is to blame for generating those *.tmp files?
Still looks OK here now, after i deleted the files last week - and Firefox has been running since then.

(In reply to Calixte Denizet (:calixte) from comment #38)

When several fonts have the same unique name, is it possible to set a precedence based on the directory they're found ?
For example, an Arial in \Windows\Fonts could have the precedence on one in \Users\Foo\AppData\Local\Temp folder.
Or maybe a .ttf, .otf, ... could have the precedence on a .tmp, wdyt ?

I'm not sure offhand whether we can do this.... note that we don't locate fonts by searching the filesystem for them, so we don't necessarily know where the file was located or what its filename is. We query Windows using the DirectWrite GetSystemFontCollection API, and use whatever it gives us.

As far as I can tell, the only way a font from Users\...\AppData\Local\Temp with a *.tmp filename could end up being used by Firefox -- as we'll never go looking in that directory ourselves -- is that it must have been registed "globally" as part of the system font collection, by whatever software created that "temporary" file. (Which I'm assuming was Acrobat, probably during a printing operation -- not necessarily when the file is simply opened/viewed -- but perhaps it's not Acrobat but some other PDF-related software that's doing this.)

So I think the "culprit" here is whatever software -- Acrobat or other -- is creating those temporary fonts and registering them with the system, and then failing to clean up. That's "polluting" the system font collection, and because the FontFace src: local(...) lookup method looks at the font's PostScript name (as required by the CSS Fonts spec), not at the family name (ID 1, which they did at least have the sense to change to a "temporary" name), it results in the wrong resource being used.

I'll see if I can come up with a mitigation we can use in Firefox, but I do think the real flaw is whatever software is inserting these mangled fonts into the system. It's essentially corrupting the system's installed font collection.

:jfkthame
Thank you for your thorough explanation, which sounds very reasonable.
However, I still note that the native PDF readers used in Chrome and Edge gets around the issue - so I assume it should be in the interest of Firefox to also get around it.

Anyway - I now know what to do if the issue arises again: Delete the *.tmp files in Users...\AppData\Local\Temp.
So I know how to live with this issue.

This is a sad hack, but aims to work around the issue that some
PDF-related software (Acrobat is suspected but not currently confirmed)
is potentially polluting the global font collection with re-encoded
subsets of standard fonts like Arial, but does not munge the psname;
these can then be returned by src:local(...) lookups, which results in
garbled or missing text.

In principle, if such fonts are "installed", Firefox is not wrong to use
them; it's just a badly-configured system. But given that it seems to be
caused by some PDF-handling software, without the user's knowledge, it
seems worth trying to avoid the problem. Simply skipping the psname of
any font with family-name *.tmp is highly unlikely to adversely affect
any real-world content.

Assignee: nobody → jfkthame
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Would it be possible to use them only if there is no alternative in the system?

Not easily, as things stand. If I'm reading the pdf.js code correctly, the "problematic" name ends up as just one of a list of things it'll try, via the standard CSS font-matching code. To then go back and reconsider a particular src:local(...) face if nothing else works out would be a pretty disruptive intervention there.

In any case, the pdf.js code looks like it would end up trying a generic like sans-serif as a last resort, which is a better bet than some random temporary subset of a standard font. At least the default fallback will have reasonable character encoding, unlike extracted subsets like this.

Note that in the reporter's case, it looks like the bad font(s) don't even necessarily have any connection with the PDF we're trying to render; they're random resources that some other software has left lying around, and probably came from other, unrelated PDFs. The only reasonable use-case for such resources is to render the exact PDF in which they were embedded. Arbitrarily accessing them as "Arial" or "Times-Roman" or whatever and using them to render other documents is never going to end well.

Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b2085aad8c83 Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=jwatt
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch

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

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox120 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(jfkthame)

Comment on attachment 9359789 [details]
Bug 1854090 - Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=#layout

Beta/Release Uplift Approval Request

  • User impact if declined: Possibly-broken text display in some PDFs on Windows, due to bad fonts installed by 3rd-party software
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce: (Unclear exactly what 3rd-party software/steps are involved in triggering the issue on a given system.)
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Narrowly targeted fix to just skip font names matching a known "temporary-file" pattern
  • String changes made/needed:
  • Is Android affected?: No

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Low-risk workaround for a failure mode that could make some PDFs unusable
  • User impact if declined: Possibly-broken text display in some PDFs on Windows, due to bad fonts installed by 3rd-party software
  • Fix Landed on Version: 121
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
Flags: needinfo?(jfkthame)
Attachment #9359789 - Flags: approval-mozilla-esr115?
Attachment #9359789 - Flags: approval-mozilla-beta?

Comment on attachment 9359789 [details]
Bug 1854090 - Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=#layout

Approved for 120.0b5

Attachment #9359789 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9359789 [details]
Bug 1854090 - Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=#layout

Approved for 115.5esr

Attachment #9359789 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
Flags: qe-verify+

Unfortunately I couldn't manage to reproduce the issue on my end, It's hard to find which 3rd-party software or steps are involved since we didn't have any lead from where to start.

Seb, Could you please verify if the issue is fixed on your end?
Thanks.

Flags: needinfo?(seb)

I am not seeing the problem at the moment, although it is intermittent so hard to be 100% sure. I will report back if I come across the problem again.

Flags: needinfo?(seb)

Could you please tell me on which Firefox you tried?

Flags: needinfo?(seb)

I'm working with release 119 at the moment, which I see from the tracking flags doesn't have the fix.

But I'm not seeing the problem since I ran a Windows update and restarted, which presumably cleaned out the temp font files which had been causing the problem.

Unfortunately I've been unable to repeat whatever created the bad font files. If I do manage to see the problem again in release 119, I'll try release 120 or 121 to check if the fix has worked.

Sorry not to be able to verify properly!

Flags: needinfo?(seb)

Could you please help us with another verification on Firefox Beta in order to change the status of this bug if it's not reproducible anymore?
You can download the latest version of Firefox Beta from here: https://www.mozilla.org/en-US/firefox/channel/desktop/
Thanks.

Flags: needinfo?(seb)

I'm not sure how I can help with this. As I said, I can't currently reproduce the bug even with the versions of Firefox which have not been fixed. Presumably because the problematic temp font files have now been automatically removed from my system.

And since I don't know how (or by which 3rd part app) the bad font files were created in the first place, I'm unable to recreate the circumstances where the bug appears.

As per your request,. I have now tried release 120 and the bug is also not showing up with this. But it doesn't really confirm the fix, since I couldn't reproduce the bug any more with 119 either.

Flags: needinfo?(seb)

Adding the Qa-not-actionable tag since this issue can't be reproduced on our side in order to be verified and the reporter can't confirm the fix also.

QA Whiteboard: [qa-not-actionable]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: