Opened 3 months ago

Last modified 2 months ago

#31209 new defect

View PDF in Tor browser is fuzzy

Reported by: null Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff68-esr
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor44-can

Description

This is open in Edge(or other normal PDF viewer, include PDF.js):
https://i.loli.net/2019/07/21/5d342843868e089809.png
This is open in Tor browser(with PDF.js):
https://i.loli.net/2019/07/21/5d342843dd2f844657.png
It's same with all PDF.

Child Tickets

Change History (9)

comment:1 Changed 3 months ago by Thorin

FYI: upstream

comment:2 Changed 3 months ago by pospeselr

The tldr for why this happens is that RFP spoofs your monitor's DPI and as a result things which render to canvas and take the screen DPI into account (google docs, js pdf renderers, etc) will have the wrong value and so the contents of the canvas element's backing frame buffer will be stretched or squished to the page content's logical size.

So for example suppose you have a high DPI screen and a page has a canvas element with logical dimensions of 100x100 but the web app would normally take DPI into account and request the framebuffer be 200x200 to match your monitor's physical dimensions. With RFP enabled, the page now thinks the physical dimensions are the same as the logical dimensions and request a 100x100 framebuffer, whose contents are now stretched to fit the 200x200 physical dimensions, resulting in blurriness.

comment:3 Changed 3 months ago by cypherpunks

I wonder, does this happen when WebRender is enabled? (on Nightly with RFP enabled)

Last edited 3 months ago by cypherpunks (previous) (diff)

comment:4 in reply to:  2 ; Changed 3 months ago by gk

Replying to pospeselr:

The tldr for why this happens is that RFP spoofs your monitor's DPI and as a result things which render to canvas and take the screen DPI into account (google docs, js pdf renderers, etc) will have the wrong value and so the contents of the canvas element's backing frame buffer will be stretched or squished to the page content's logical size.

So for example suppose you have a high DPI screen and a page has a canvas element with logical dimensions of 100x100 but the web app would normally take DPI into account and request the framebuffer be 200x200 to match your monitor's physical dimensions. With RFP enabled, the page now thinks the physical dimensions are the same as the logical dimensions and request a 100x100 framebuffer, whose contents are now stretched to fit the 200x200 physical dimensions, resulting in blurriness.

Are we missing a "Is this a privileged context and thus no RFP"-check here somewhere?

comment:5 in reply to:  4 Changed 3 months ago by tom

Replying to gk:

Are we missing a "Is this a privileged context and thus no RFP"-check here somewhere?

I don't know why it took you spoon-feeding this to me; but yeah. I investigated and sure enough I think the fix is pretty simple.

I put a patch up at https://bugzilla.mozilla.org/show_bug.cgi?id=1537955

comment:6 Changed 3 months ago by gk

Keywords: ff68-esr added; ff60-esr removed

comment:7 Changed 3 months ago by cypherpunks

Are we missing a "Is this a privileged context and thus no RFP"-check here somewhere?

Can that be exploited as an RFP bypass?

comment:8 in reply to:  7 Changed 3 months ago by tom

Replying to cypherpunks:

Are we missing a "Is this a privileged context and thus no RFP"-check here somewhere?

Can that be exploited as an RFP bypass?

I don't think so; but if you can figure out a way to run javascript inside a pdf or inject it into an iframe whose url is a pdf then yeah.

comment:9 Changed 2 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

Note: See TracTickets for help on using tickets.