913960 - Provide some sort of attribute in the HTML that allows the PDF viewer to be detected

Status: RESOLVED WONTFIX

(Firefox :: PDF Viewer, enhancement, P4)

Description

[Mike Kaply [:mkaply]]

Currently it's not easy for an add-on to override anything about the PDF viewer (remove print button for example), because:

1. The CSS files are resource URLs which can't be overridden.
2. There's nothing in the HTML that can be used as a selector to detect the PDF viewer.

We should add some attribute to the HTML or BODY so that custom CSS rules can be written for the viewer.

Comment 1

[Brendan Dahl [:bdahl]]

Would a css class on the body be enough?

Comment 2

[Mike Kaply [:mkaply]]

(In reply to Brendan Dahl [:bdahl] from comment #1)
> Would a css class on the body be enough?

That should be enough.

Was there a reason these files were done as resource files instead of chrome files?

Being resource files means that can't be overridden.

Comment 3

[Brendan Dahl [:bdahl]]

We run pdf.js under a resource url so it runs with content only permissions.  We could perhaps host the css under a chrome url.

Comment 4

[Mike Kaply [:mkaply]]

(In reply to Brendan Dahl [:bdahl] from comment #3)
> We run pdf.js under a resource url so it runs with content only permissions.
> We could perhaps host the css under a chrome url.

That would be helpful, but the attribute is probably enough, as long as it was unique enough.

Since there's no way to detect PDF.js loads in a page load handler (is there?)

Comment 5

[Adam Moore]

Really, this is about being able to customize the pdf viewer in an extension like we can other chrome resources.  The approach chosen appears to have favored something that is cross-browser compatible over something that is a first-class member of the Firefox ecosystem.  I'd like to be able to define an overlay or override to customize the viewer.  Having to resort to detecting pdf.js on page load by looking for a class on the body would be brittle and hard to discover. But right now I have to patch Firefox to customize it at all, so of course I'll take it if that is all we can do.

Comment 6

[Mike Kaply [:mkaply]]

It doesn't look like this was ever done. This would still be really nice to have.

Comment 7

[Mike Kaply [:mkaply]]

Closing WONTFIX.

The original motivation was XUL-era add-ons wanting to customize the PDF viewer's chrome by patching its DOM, which legacy extensions could attempt via resource URL overrides. That extension model no longer exists. WebExtensions don't have a path to inject into the built-in viewer's resource://pdf.js/ document, and the PDF viewer has since grown its own first-class UI (annotation, editing, signing) on a trajectory that isn't intended to be a customization surface for third parties.

Enterprise/admin tweaks happen today via the pdfjs.* preferences and enterprise policies. If a specific knob is missing, that's the better place to file — adding a body attribute to mark the viewer would just create a stable hook for a use case Firefox isn't designed to support.