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

Steps to reproduce:

1. In about:preferences, under Applications, set action for PDF documents to "Open in Firefox".
2. Enable privacy.resistFingerprinting.
3. Navigate to a URL that returns a PDF document that can be displayed by Firefox. For example, navigate to https://web.pa.msu.edu/people/duxbury/courses/phy480/Cpp_refcard.pdf.
4. Firefox may display a 'Allow pdf.js t use your HTML5 canvas image data?' dialog near the address bar. If displayed, ignore the prompt or click on [X] 'Close this message' in top-right corner of the dialog.
5. If Sidebar is not visible, click on Toggle Sidebar button to display the sidebar.

Actual results:

Sidebar displays thumbnails of PDF document pages. Each thumbnail is a white rectangle hatched with a different colour. Thumbnails are not actual representations of the PDF pages.

Work-around:

1. Allow HTML5 canvas for the specified URL.
2. Refresh page.

Expected results:

Each thumbnail in the sidebar should be a faithful representation of the actual PDF document page, regardless of privacy.resistFingerprinting setting.
Firefox internal PDF viewer should not need to ask for canvas permissions.

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

Yes; we should be able to allow these thumbnails through (I'm assuming that pdf JS can't read DOM data.)

It looks like this was discussed ~5 years ago on tor trac and on the pdf.js github, the conclusion then seems to be giving pdf.js an exemption from the canvas routines. My quick guess is that pdf.js's recent move to being an addon from an extension broke those special privileges and they need to be reinstated.

Could find a regression range in using mozregression:
https://mozilla.github.io/mozregression/

Regression window:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=196dadb2fe500e75c6fbddcac78106648676cf10&tochange=684b9ee0468e6560b00c69231adfe1b7e68d58a4

Suspect: Bug 967895

While I really cannot claim to understand the following code https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/dom/canvas/CanvasUtils.cpp#82-87, I nonetheless cannot help thinking that the particular file-check used there isn't correct.

Note that the (thumbnail) canvases are not being created in that particular file, and the following search suggests that most call-sites (be it in C++ or JS code) are checking the principal or origin for "resource://pdf.js/web/viewer.html" respectively "resource://pdf.js".

Maybe the code in CanvasUtils.cpp could simply utilize this existing helper: https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/dom/base/nsContentUtils.cpp#6717-6725, unless I'm completely misunderstanding things?

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

For more information, please visit auto_nag documentation.