1537955 - privacy.resistFingerprinting option makes PDFs rendering blurred

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P3)

Description

[Daniel]

Attachment: blurred and reference screenshot of option toggled on and off

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

Steps to reproduce:

0. Use a high resolution (HiDPI) display
1. Enable privacy.resistFingerprinting
2. Load https://juliareda.eu/wp-content/uploads/2019/02/Copyright_Final_compromise.pdf

Actual results:

The PDF rendering is blurred to the point where it’s difficult to read the text.

Expected results:

Either Firefox should render the PDF with good quality, or failing that defer to another PDF reader.

Comment 1

[Tom Ritter [:tjr]]

We seem to have a lot of burring bugs lately. Did something change to make the devicePixelRatio or whatever start causing this?

Comment 2

[Bruno Pagani]

@tjr: The bug is not new, I already reported that 1 year ago, you even participated to the discussion (https://bugzilla.mozilla.org/show_bug.cgi?id=1428331). What is likely changing the rate of reports is more and more HiDPI devices together with more and more RFP users.

Comment 4

[KOLANICH]

should PDF.JS browser component be made privileged as a temporary solution?

Comment 5

[Ethan Tseng [:ethan]]

I am not quite sure but this might be caused by spoofing the property window.devicePixelRatio.

Comment 6

[Tom Ritter [:tjr]]

Attachment: Bug 1537955 - Do not spoof DevicePixelRatio for pdfs

pdfs should not have a way to exfiltrate the true device pixel ratio,
so it is safe to provide the correct value, enabling them to be rendered
correctly.

Comment 7

[Tom Ritter [:tjr]]

.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/85385b4957e3
Do not spoof DevicePixelRatio for pdfs r=Ehsan

Comment 9

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/85385b4957e3

Comment 10

[Tom Ritter [:tjr]]

Had someone test this for me and confirmed it worked.

Comment 11

[Tom Ritter [:tjr]]

Comment on attachment 9081855 [details]
Bug 1537955 - Do not spoof DevicePixelRatio for pdfs

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fix for Tor, who only uses ESR
• User impact if declined: Tor will have to carry the patch
• Fix Landed on Version: 70
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Only affects the Resist Fingerprinting mode; which is a non-default mode. Additionally, very small patch.
• String or UUID changes made by this patch:

Comment 12

[Tom Ritter [:tjr]]

[Tracking Requested - why for this release]: Patch for Tor

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9081855 [details]
Bug 1537955 - Do not spoof DevicePixelRatio for pdfs

Fix for PDF rendering when resistFingerprinting is enabled (needed by Tor browser, off by default for Firefox). Approved for 68.1esr.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/5e336543485a

Comment 15

[Bruno Pagani]

I’m still getting this issue on Firefox Nightly (currently 20190813, but haven’t seen it working since it landed), but not in default conditions: if I try in a clean profile it works, but in my existing profile PDFs are still blurred unless I disable RFP (so it’s not something else causing this by itself, but something that in conjunction with RFP makes this bugfix ineffective). Not sure what can be causing this, but if you could provide me some debugging instructions we might be able to pinpoint it.

Comment 16

[Tom Ritter [:tjr]]

(In reply to Bruno Pagani from comment #15)

I’m still getting this issue on Firefox Nightly (currently 20190813, but haven’t seen it working since it landed), but not in default conditions: if I try in a clean profile it works, but in my existing profile PDFs are still blurred unless I disable RFP (so it’s not something else causing this by itself, but something that in conjunction with RFP makes this bugfix ineffective). Not sure what can be causing this, but if you could provide me some debugging instructions we might be able to pinpoint it.

I cannot imagine anything about this patch that relies on your existing state. Weird! Have you changed any prefs beginning with 'pdfjs'? Tried new pdfs that wouldn't be cached?

Comment 17

[Bruno Pagani]

No, they are no prefs beginning with pdfjs that don’t have their default value (they are many other prefs having non-default values though, if I get some time I could try to find if any particular one is causing this by bisecting).

And I’ve tried with random PDF on the web, same issue. Also note that toggling RFP and reload the PDF page gives a correct rendering, so I doubt this is a cache issue.

Comment 18

[Ben]

I'm still seeing this problem, on Mac OS 10.15 and Firefox 78.0.0.2 with a high-DPI monitor. Disabling privacy.resistFingerprinting fixed the blurry PDFs for me, yet this bugfix was integrated a long time ago. Maybe it missed some cases?

Comment 19

[Tom Ritter [:tjr]]

(In reply to Ben from comment #18)

I'm still seeing this problem, on Mac OS 10.15 and Firefox 78.0.0.2 with a high-DPI monitor. Disabling privacy.resistFingerprinting fixed the blurry PDFs for me, yet this bugfix was integrated a long time ago. Maybe it missed some cases?

Is it all PDF's Could you provide a link to an example?

Comment 20

[Ben]

(In reply to Tom Ritter [:tjr] (OOTO until Aug 3) from comment #19)

Is it all PDF's Could you provide a link to an example?

It's the same for every PDF. All were blurry prior to disabling privacy.resistFingerprinting, and now all are sharp and clearer. n.b. All of the PDFs I've opened have looked fine in the default Mac PDF viewer app.

Comment 21

[Ben]

Sorry, I forgot to mention what might be an important detail: My computer setup has two monitors, the main display being high-DPI, but the secondary one is standard DPI. All the Firefox windows are opened on the main monitor only.

Comment 22

[Bruno Pagani]

FWIW, I’m still in the same status as above — working in clean profile, not in my current one —, but did not have time to debug this further. So there might still be some tricky behaviours there.