I don't have easy steps to reliably reproduce this but I probably see it on average after about 2-3 hours of PDF reading. The issue is that some symbols (I believe it is "some fonts") display incorrectly in the document I'm reading. Reloading the page immediately fixes the symbols. I've attached a screen shot of a page, before and after reloading the page. Check, for example, the second line, where Prt(A) was incorrectly rendered as \eta\phi(A). Some potentially useful points (I haven't confirmed if they are important):

1. I am reading this document from a file on my hard drive, not the web.
2. The document in the images is freely available here [1].
3. I am currently on the 01-05-20 nightly build on Windows.
4. I read a lot of PDFs. I'd say that this popped up, roughly, sometime in the last month.
5. I have gfx.canvas.remote set to true. I don't know if this still on in nightly by default or not. This is part of Bob Owen's project to move 2D canvas operations out of the content process. I set that to true many months ago but, again, just recently started seeing this.
6. Reloading the page seems to fix it every time. Other things, like changing tabs or switching window focus, seem to have no effect on the bug.
7. I haven't seen the issue when just opening a document, but this may be a coincidence. I have always come across it after scrolling through the document.

[1] http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf

I haven't been able to reproduce locally yet. When this happens do you see any messages in the web console?

I didn't notice anything unusual in the console.

I was wrong about the frequency and severity of the issue. I now see this pretty frequently (still can take 1-2 hours to show though) and it can get to be very extreme. A few times, the page has been so garbled its essentially all an unintelligible, randomly strewn collection of font symbols where simple text should be. I'll try to get more useful pics and info. I have been focused on reading this particular pdf so this may be a coincidence but I haven't seen the bug in any of the other pdfs I've read.

Jonathan,
Do you know if gecko or windows ever unloads fonts after they are unused for awhile? I thought this may be a bug with pdf.js, since we will clear out fonts after inactivity. However, I've tried lowering that timeout, but I still am not able to reproduce the bug.

^

I haven't been using pdf.js much, which is why I've been silent, but I do still see this issue (most recently in the Feb 3rd nightly). I recently saw it again and have output from the web and browser consoles. I don't know if there is anything relevant in them but I'm attaching them. The only info I can add is that I think I'm seeing the problem happen fairly soon after navigating in the document with links (so, clicking page links in the pdf and/or using the browser back/forward buttons, again, to navigate inside of the document).

Adding this to underscore how bad the situation can be.

The bad image, repaired after reload.

1. Do you have any web extensions enabled?
2. I also noticed in the above log, the PDF url is a local file URL. Does this issue only happen when you're opening local "file:///" urls? Or does it happen for pdfs on regular URLs too?

If possible, could you try running Firefox in safe mode with extensions disabled for a bit and see if you still get the same problem? That would allow us to see one of the extensions is causing problems.

(In reply to Brendan Dahl [:bdahl] from comment #14)

If possible, could you try running Firefox in safe mode with extensions disabled for a bit and see if you still get the same problem? That would allow us to see one of the extensions is causing problems.

Another possible explanation is that this bug could be related to using gfx.canvas.remote = true, since bug 1607630 comment 0 mentions using that.

I assume that means canvas drawing is happening in a separate process? I can imagine that might be an issue, because it means the font resource(s) that pdf.js extracts from the PDF and activates via @font-face will need to be sent over to the canvas drawing process, and then instantiated there as well; that may be happening asynchronously, such that the font isn't yet ready at the time of the first drawing operation that wants to use it. (And maybe the drawing process flushes its caches or even shuts down or something, if not used for a while?)

I've spent a good deal of time with this, running in a new profile and in safe mode. I did not reproduce the issue. I'm pretty sure that I would have, if the issue was present. There could be other explanations for this, like something unexpectedly different in my profile or that performance under my main profile is not nearly as good as with a fresh one (I tend to have a LOT of tabs open) but I'm leaning toward suspecting that gfx.canvas.remote=true may not be innocent after all.

handyman - are you still able to reproduce this?

This is now affecting also the PDF.js test-suites, after they were recently updated to run on Firefox Nightly 77.

It's looks especially bad on Windows, which I've also confirmed locally, with fonts randomly failing to load correctly; please see e.g. these recent test results: https://github.com/mozilla/pdf.js/pull/11491#issuecomment-620761303

handyman - are you still able to reproduce this?(In reply to Jonas Jenwald [:Snuffleupagus] from comment #19)

This is now affecting also the PDF.js test-suites, after they were recently updated to run on Firefox Nightly 77.

It's looks especially bad on Windows, which I've also confirmed locally, with fonts randomly failing to load correctly; please see e.g. these recent test results: https://github.com/mozilla/pdf.js/pull/11491#issuecomment-620761303

Do these issues go away if you set the pref gfx.canvas.remote=false in your tests?

Do these issues go away if you set the pref gfx.canvas.remote=false in your tests?

Yes, as far as I can tell that fixes things.

Locally I first noticed this when bug 1547286 landed in Nightly (unfortunately I didn't have time to follow-up then), and I've also been seeing intermittent font corruption in PDF files during "normal" browser usage as well.

Thanks for testing that.
Do you have documents and STR, so that I can try and track this down?

(In reply to Bob Owen (:bobowen) from comment #22)

Thanks for testing that.
Do you have documents and STR, so that I can try and track this down?

Well the highly intermittent nature of this bug makes STR somewhat difficult to provide unfortunately.

Unless you're simply asking about how to run the PDF.js test-suite locally, in which case please see:

1. https://github.com/mozilla/pdf.js#getting-the-code
   This contains the necessary clone/setup instructions.
2. https://github.com/mozilla/pdf.js/wiki/Contributing#4-run-lint-and-testing
   To summarize that page, after you've installed the necessary dependencies (see above) you
   • Generate reference images, with the gulp makeref --noChrome command.
   • Run the test-suites, using the gulp test --noChrome command.

Thanks for the links.
I can reproduce this in the browsertest runs, but I don't seem to be able to reproduce when opening the PDFs in the actual browser.
Am I right in thinking that the PDFs are rendered slightly differently for the tests? (It looks that way from driver.js)

Also have you managed to reproduce ever when opening the PDF in the browser?

(In reply to Bob Owen (:bobowen) from comment #24)

Am I right in thinking that the PDFs are rendered slightly differently for the tests? (It looks that way from driver.js)

Sorry, different how? I'm not sure I understand exactly what you're asking here.

The point here is that everything worked fine previously, when e.g. the tests ran against Firefox 76, and there should absolutely not be any font-rendering failures when running gulp test --noChrome directly after gulp makeref --noChrome.

Also have you managed to reproduce ever when opening the PDF in the browser?

As mentioned previously it's highly intermittent, but the following is hopefully useful:
Reload http://mirrors.ctan.org/info/lshort/english/lshort.pdf over and over, in Firefox Nightly 77 on Windows 7, some type of font corruption happens at approximately every 25-50 reload.

(In reply to Jonas Jenwald [:Snuffleupagus] from comment #25)

(In reply to Bob Owen (:bobowen) from comment #24)

Am I right in thinking that the PDFs are rendered slightly differently for the tests? (It looks that way from driver.js)

Sorry, different how? I'm not sure I understand exactly what you're asking here.

The point here is that everything worked fine previously, when e.g. the tests ran against Firefox 76, and there should absolutely not be any font-rendering failures when running gulp test --noChrome directly after gulp makeref --noChrome.

I meant that test/driver.js has code for rendering and rasterizing the text (albeit using pdfjsLib), which might be slightly different to what happens in the viewer, not that the reference images and test images used different code.
I was just trying to grasp at something, because it seems to appear much more often in the tests.

(In reply to Bob Owen (:bobowen) from comment #26)

I meant that test/driver.js has code for rendering and rasterizing the text (albeit using pdfjsLib),

For the purpose of this bug, I think it's safe to ignore the text tests. (The problem here rather seem to be that canvases lose loaded fonts intermittently, as far as I can tell.)

Please note the edited https://bugzilla.mozilla.org/show_bug.cgi?id=1607630#c25, where I've included the only STR that I can come up with that applies directly in the browser.

(In reply to Jonas Jenwald [:Snuffleupagus] from comment #25)
...

As mentioned previously it's highly intermittent, but the following is hopefully useful:
Reload http://mirrors.ctan.org/info/lshort/english/lshort.pdf over and over, in Firefox Nightly 77 on Windows 7, some type of font corruption happens at approximately every 25-50 reload.

Thanks, I can reproduce with that file, as you say it pretty rare, but hopefully it's enough to track down the problem.

I've found the problem.
The way we store UnscaledFonts in the recorder is flawed, meaning if a new font uses the same pointer as an old one, we will pick up the old font in the recording.

https://treeherder.mozilla.org/#/jobs?repo=try&duplicate_jobs=visible&revision=772475ee10b6eabc7058906889b6ca1895cd0dc5

https://hg.mozilla.org/mozilla-central/rev/0a27517b3e93

Reproduced the issue with Firefox Nightly 78.0a1 (2020-05-19) on Windows 10x64.
Verified as fixed with Firefox Nightly 78.0a1 (2020-05-20) on Windows 10 x84 and Windows 7 x86.