1518473 - Fonts are broken in Print Preview mode and printed output if several other files are previewed

Status: RESOLVED DUPLICATE of bug 1524640

(Core :: Print Preview, defect, P3)

Description

[Timea Cernea [:tbabos][inactive]]

Attachment: Video of the issue

[Affected versions]
66.0a1 (2018-01-08)
65.0b8 (64-bit)
64.0 (64-bit)

[Affected platforms]
Windows 7/10 x64
Windows 8 x32
Mac OS 10.13

[Steps to reproduce]

1. Open any firefox version with a new profile
2. Open https://drive.google.com/open?id=0BzOV3ybvBASXcTFiVngyRmx3UkE and click on the Print button (the one from the reader)
3. Open https://bug1392028.bmoattachments.org/attachment.cgi?id=8906309 in a different tab
4. Open https://drive.google.com/file/d/0BzOV3ybvBASXdkxsaGx3OU9fTWc/view in a different tab
5. Open https://bug1308259.bmoattachments.org/attachment.cgi?id=8798493 in a different tab
6. Hamburger button -> Print preview for all the tabs starting from the last one
7. Print Preview the first tab and check the font

[Expected result]
The fonts should be displayed correctly in Print Preview mode like in the rest of the documents

[Actual result]
The fonts are "broken" in Print Preview mode and in the printed output as well.

[Note]:
Please check the attached video to have a better understanding of the steps.

Comment 1

[Rares Doghi, Desktop QA]

Hi, This issue seems to reproduce when you Try to print the Source File which will be downloaded temporary and transformed into an HTML file after which when you try to print that preview it will result in the Above mentioned Actual Results.

You might have to Print an actual File in order to see the issue since it looks fine in Print Preview.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: pdf that has trouble when print-reviewed from PDF.js (after print-previewing other stuff)

I can reproduce, at least some of the time.

In the video, it looks the "page" that triggers an issue (when print-previewed) is actually a PDF file, viewed via the built-in PDF.js viewer. Here's that PDF, for convenience.

Comment 4

[Tim van der Meij]

I looked at the duplicate issue and I'm a bit unsure about the regression window. Are we absolutely sure the bug is in https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5097db630d1fb51f7f3fcd5523a924fa823e77ce&tochange=caa65bf34838ab7861dcfed3ae59f9f6ed89fc0b since I also read that it cannot be reproduced consistently? I'm asking because I checked all the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1523366#c4 and I don't really see how any of them are linked to this particular behavior.

I know that we had issues with the font loading API for printing before and this looks somewhat similar to e.g., https://github.com/mozilla/pdf.js/issues/6738 and https://github.com/mozilla/pdf.js/issues/7092. I also know that we have (had?) some cleanup logic for pages and fonts, but I don't know if that is also applied to printing.

What I did find is https://github.com/mozilla/pdf.js/blob/25446dbd8d0fa0afdd4789965c16335602d825bf/src/display/font_loader.js#L174-L187, which could be relevant here. Since Firefox 63 we use the font loading API again, so it could be that there are still issues with that.

Comment 5

[Tim van der Meij]

Brendan, since you were involved with https://bugzilla.mozilla.org/show_bug.cgi?id=1473742, do you perhaps have more information about if the issue here could be related to the font loading API?

Comment 6

[Brendan Dahl [:bdahl]]

I checked out the raw changeset and it looks like https://github.com/mozilla/pdf.js/pull/9340 was included. I'm guessing it didn't make it into the bug release notes since it was a very old PR that was merged and the release notes tool only looks back so far.

As for the issue, my guess is that this was an issue before #9340. However, it is now just more obvious, since if the font isn't loaded it will look like gibberish.

Now to figure out why print preview doesn't load the fonts from pdf.js....

Comment 7

[Timea Cernea [:tbabos][inactive]]

Investigated a bit more using mozregression and found a longer range:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5097db630d1fb51f7f3fcd5523a924fa823e77ce&tochange=43a95f0f47256ac54ce6bb2044216de7a9406574

The last pushlog with the "bad" build was:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=00056b5eb7140780986df16e69214f4a20e0e42b&tochange=d3e7d6d6e0d565564575071bfae0abd63e046c77

I ended up with the final pushlog being bugs from WebPayments API (I don't think it has anything to do with this):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ffce46424c69ce49b0a8509dab4fccdcb71e3b4c&tochange=d3e7d6d6e0d565564575071bfae0abd63e046c77

Given that the issue is quite tricky to reproduce an accurate range is hard to get. I hope the above can help the development team to figure out the culprit.

Comment 8

[Brendan Dahl [:bdahl]]

I believe this is a duplicate of bug 1524640, see my comment https://bugzilla.mozilla.org/show_bug.cgi?id=1524640#c1

This has likely been a problem since pdf.js was first introduced into Firefox, but it's just now more apparent because of how we load fonts.

@Timea you should be able to reproduce this consistently if you wait 30s until you print the PDF.

Comment 9

[Alice0775 White]

(In reply to Timea Babos from comment #7)

Investigated a bit more using mozregression and found a longer range:

https://hg.mozilla.org/integration/mozilla-inbound/
pushloghtml?fromchange=5097db630d1fb51f7f3fcd5523a924fa823e77ce&tochange=43a9
5f0f47256ac54ce6bb2044216de7a9406574

The last pushlog with the "bad" build was:

https://hg.mozilla.org/integration/mozilla-inbound/
pushloghtml?fromchange=00056b5eb7140780986df16e69214f4a20e0e42b&tochange=d3e7
d6d6e0d565564575071bfae0abd63e046c77

I ended up with the final pushlog being bugs from WebPayments API (I don't
think it has anything to do with this):
https://hg.mozilla.org/integration/mozilla-inbound/
pushloghtml?fromchange=ffce46424c69ce49b0a8509dab4fccdcb71e3b4c&tochange=d3e7
d6d6e0d565564575071bfae0abd63e046c77

Given that the issue is quite tricky to reproduce an accurate range is hard
to get. I hope the above can help the development team to figure out the
culprit.

Maybe, you have missed bad build between cset caa65bf34838 and ffce46424c69.

See Bug 1523366 comment#2, I can reproduce the problem on cset caa65bf34838.
So, definitely regressed by Bug 1489996 - Update pdf.js to version 2.0.843.