1454760 - content_scripts won't load with pdf.js tabs

Status: REOPENED

(WebExtensions :: General, enhancement, P5)

Description

[Paul Heil]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

My extension loads a content_script when the user opens a pdf.  This works fine in 59.0.2 and earlier, but as of FF60.0b13 (Probably earlier betas had this issue I just didn't notice) the script is no longer loaded. 


Actual results:

content_scripts in pdf.js documents are not loaded and no warnings or errors are shown the console.


Expected results:

The script should load and be applied to the page.

Comment 1

[Paul Heil]

Attachment: bug_1454760_test_case-0.0.1.zip

Test case url https://static.mozilla.com/moco/en-US/pdf/mozilla_privacypolicy.pdf

Comment 2

[u554753]

Please correct if this isn't the right component. Not sure if this is a PDF Viewer issue, or an Extension Compatibility issue given the information in Comment 0.

Comment 3

[Kris Maglione [:kmag]]

This is intentional.

Comment 4

[Paul Heil]

Can you provide some reasoning behind this change?  A bug?  

What's special about pdfs versus other web content that they need this protection?   I could intercept all PDFs and load my own version of pdf.js, but that's a lot of bloat.

Chrome doesn't have this behavior.

Comment 6

[Adomas]

Is this expected to work in the future or should extension developers that relied on the content scripts working in pdf pages should look for an alternative solution?

Comment 7

[Kris Maglione [:kmag]]

(In reply to Adomas from comment #6)
> Is this expected to work in the future or should extension developers that
> relied on the content scripts working in pdf pages should look for an
> alternative solution?

It is not expected to work in the future, no. PDF pages are part of the browser chrome, not web content.

Comment 8

[Dan Stillman]

While that's true on a technical level, it's a distinction that will be lost on many users (the PDFs themselves are web content, after all), and this will affect any extension that uses in-page UI. This is also something that works in both Chrome and Safari. Are there plans for non-page content-area UI capabilities for WebExtensions to replace the lost functionality here?

Comment 10

[juraj.masiar]

As there is no technical difficulty enabling this, may I suggest introducing new about:config setting for power-users? (we are all power-users here so let's do this one for us :)).

There is plenty of add-ons that would help in PDF viewer, for example ScrollAnywhere:
https://addons.mozilla.org/en-US/firefox/addon/scroll_anywhere/

Comment 14

[paolo.caminiti]

It is just ridicolous that this "regression" is here to stay. Mozilla idea of enabling users is by limiting their power over they content in deliberate ways. They will just turn to chrome.

Ridicolous as in:
- it defeats the whole idea of bringing pdf format closer to open html content (then use a native fast viewer).
- it limits the end user.
- it limits developers.
- it is a regression of what's possible to achive with firefox.

At least an epxlicit manifest permission should unlock this. In the mean time just make it clear to customers that chrome is their best bet to have full access of their content.

Comment 15

[m.donsk]

Add-ons support in pdf documents was the only reason for me and many other people to use Firefox for viewing pdf documents.
Now I have lost a convenient way of reading pdf books, because the extension that I used for translating words from English to my native language doesn't work anymore :(
Could you, please, add a setting to the about:config page that allows access to pdf.js content for browser extensions?

Comment 16

[Kris Maglione [:kmag]]

(In reply to m.donsk from comment #15)
> Could you, please, add a setting to the about:config page that allows access
> to pdf.js content for browser extensions?

I'd probably accept a patch for that.

Comment 17

[Dan Stillman]

An about:config setting wouldn't let extension developers restore the lost functionality for the vast majority of users, and it seems odd to provide an option to restore something that was disabled for security reasons. (If this is still a security issue, do you really want extension developers to instruct users to turn it back on?)

Can the security issue not be addressed in a real way that allows us to continue interacting with PDF pages like we can in Chrome?

Comment 18

[Brendan Dahl [:bdahl]]

(In reply to Dan Stillman from comment #17)
> Can the security issue not be addressed in a real way that allows us to
> continue interacting with PDF pages like we can in Chrome?

Chrome's PDF viewer lets web extensions interact with it?

Comment 19

[Dan Stillman]

> Chrome's PDF viewer lets web extensions interact with it?


Sorry, I just meant that you can inject into the HTML page that contains the viewer, the same as it was in Firefox before this change. In our extension that lets us show various UI elements (dialog boxes, notifications, popups) when the user saves a PDF, the same as we do on regular webpages. Any alternative that let us show content-pane UI for PDFs would be sufficient in our case.

From above posts it sounds like some other extensions could actually read/modify the contents of the PDF in Firefox. I assume that part isn't possible in Chrome (and somewhat of a leaky abstraction from pdf.js in Firefox, though a neat one).

Comment 20

[jscher2000]

(In reply to m.donsk from comment #15)
> Now I have lost a convenient way of reading pdf books, because the extension
> that I used for translating words from English to my native language doesn't
> work anymore :(

As a short-term workaround for viewing PDFs you already downloaded, you can use the PDF.js demo page at

https://mozilla.github.io/pdf.js/web/viewer.html

Near the right end of the black toolbar there is an Open File button which allows you to replace the sample PDF with one from your system. Extensions can inject content scripts into this viewer because it's all web code, no privileged code.

Comment 21

[Zack]

Why is it that the internal PDF viewer of Firefox has not as much options as this demo ?

And why can this demo use any of my add ons while the internal viewer cannot ?
That seems so dumb.

Comment 22

[Kris Maglione [:kmag]]

(In reply to Zack from comment #21)
> Why is it that the internal PDF viewer of Firefox has not as much options as
> this demo ?
> 
> And why can this demo use any of my add ons while the internal viewer cannot
> ?

The answer to the second question is essentially the same as the answer to your first. The built-in PDF viewer has more options than the one loaded in normal web content because it also has more privileges than the one loaded in normal web content.

Comment 23

[Zack]

(In reply to Kris Maglione [:kmag] from comment #22)
> The built-in PDF viewer has more options than the one loaded in
> normal web content because it also has more privileges than the one loaded
> in normal web content.

I understood this much.
But why does the internal viewer not have this much privileges ?
And if the demo has them while offering better options, why do Firefox not give us this one approach instead ?

Comment 24

[jscher2000]

Hi Zack, the demo page is a web app, so Firefox applies the rules applicable to regular web pages to the viewer (including the rendered PDF). (You can use the web app all you want, but I don't know of a way to set it as an automatic handler for web-based PDFs served as application/pdf.)

When built into Firefox, the viewer is treated as part of the browser, meaning the viewer (including the rendered PDF) becomes a privileged page that extensions cannot modify.

Comment 25

[Zack]

(In reply to jscher2000 from comment #24)
> Hi Zack, the demo page is a web app, so Firefox applies the rules applicable
> to regular web pages to the viewer (including the rendered PDF). (You can
> use the web app all you want, but I don't know of a way to set it as an
> automatic handler for web-based PDFs served as application/pdf.)
> 
> When built into Firefox, the viewer is treated as part of the browser,
> meaning the viewer (including the rendered PDF) becomes a privileged page
> that extensions cannot modify.

Then, why don't we have this web app locally instead of the current internal pdf viewer ?

Comment 27

[Rob Wu [:robwu]]

Bug 1457500 is about developing a new content handling extension API.

https://github.com/mozilla/pdf.js/issues/8533 is about creating a WebExtension version of PDF.js

I will try to see if it is feasible to develop the API and/or the extension in such a way that other extensions can interface with it.

To get a better understanding of why extension developers want to run scripts in PDF pages, please share your use case if it is not convered in this bug or the linked duplicates. If you want to have a conversation, join #webextensions at irc.mozilla.org and ping me (IRC nick: robwu_nl), or send me an e-mail.

Comment 28

[juraj.masiar]

You may want to ask it here as well:
https://bugzilla.mozilla.org/show_bug.cgi?id=1371786

It's the same issue, but about Reader mode.

Comment 29

[tumpio]

(In reply to Rob Wu [:robwu] from comment #27)
> Bug 1457500 is about developing a new content handling extension API.
> 
> https://github.com/mozilla/pdf.js/issues/8533 is about creating a
> WebExtension version of PDF.js
> 
> I will try to see if it is feasible to develop the API and/or the extension
> in such a way that other extensions can interface with it.
> 
> To get a better understanding of why extension developers want to run
> scripts in PDF pages, please share your use case if it is not convered in
> this bug or the linked duplicates. If you want to have a conversation, join
> #webextensions at irc.mozilla.org and ping me (IRC nick: robwu_nl), or send
> me an e-mail.

Required for mouse gesture add-ons.

Comment 30

[paolo.caminiti]

> To get a better understanding of why extension developers want to run
> scripts in PDF pages, please share your use case if it is not convered in
> this bug or the linked duplicates. If you want to have a conversation, join
> #webextensions at irc.mozilla.org and ping me (IRC nick: robwu_nl), or send
> me an e-mail.

For all the same reasons we develop extensions for webpages.
This being also the only advantage of an html viewer bridging the gap between the orrible pdf format and the open web.

Comment 32

[Paul Dickler]

My extension "EdgeWare" normally allows the user to assign and use such actions as changing the active tab, closing tabs, and many more things.
Once landed on a PDF-page, these are all impossible, thus breaking the user's flow of actions.
It's as bad as not being able to execute my addon in "reserved" domains like "mozilla", but that's another "feature"...

Comment 33

[Eichi]

Firefox Developer Edition. 62.0b17 (64-Bit).

Same Problem here. I can't execute any content scripts on a PDF-page (Firefox issue, Google Chrome ok). The only way i found:

"permissions": [
...
"mozillaAddons",
"resource://*/*""
]

...but that will not work in production. Why was this done? Bug or "feature"?

Comment 34

[Utkarsh]

> To get a better understanding of why extension developers want to run scripts in PDF pages, please share your use case if it is not covered in this bug or the linked duplicates.

I had created a small extension (arXiv-title-fixer) which set a more useful <title> on the PDFs. 

> Chrome's PDF viewer lets web extensions interact with it?

The same extension is available on Chrome as well and is working well there.

Comment 35

[Jeenu]

I'd like to chime in and say that a couple of extensions that I both wrote and use were left broken because of this, and would very much like it back!

Comment 36

[ciprian.tomoiaga]

The arXiv-title-fixer extension is really needed for anyone doing research and it is currently broken due to this bug :(

Comment 37

[Per Johansson]

So this bug is intentional? It is still a bug as far as we users are concerned.

My extension won't work on PDF content any more, so it has lost a part of its functionality due to this bug. Judging from the discussion above, I'll have to ask users to switch to another browser unless the bug is fixed.

Comment 38

[hai.phan]

My addon Read Aloud stopped working on PDF and there's no workaround. Before, I call PDFJS to grab the doc content to read aloud. Even without PDFJS I could still use content script to grab the PDF file via same-origin AJAX. But now, have no way to access what the user is looking at.

Comment 39

[j3.soon]

Sorry, I still don't know why content_scripts aren't allowed in PDF.js at the first place. Are there any obvious bugs or loopholes?
I'm also trying to use arXiv-title-fixer on Firefox, but it stopped working due to this bug.

However, I somehow achieved the results by some hacky work around in: https://github.com/j3soon/arxiv-utils

First, I intercept the PDF requests, and launch my custom extension page instead.
Second, my custom page embeds the original PDF into its html content.
Third, seems like I can do anything I like in my custom page now...

I wonder if this hacky work around is a vulnerability?

Thanks in advance!

Comment 41

[Devin Bayer]

With Firefox 70 the scrollbar in PDF documents is how unusable - the position is the same grey as the background. For normal pages I can use custom styles from an extension to fix the color. It would be great if this ability wasn't nurfed in the PDF viewer.

Comment 42

[Botond Ballo [:botond]]

(In reply to Devin Bayer from comment #41)

With Firefox 70 the scrollbar in PDF documents is how unusable - the position is the same grey as the background.

It might be worth filing a separate bug for this. See bug 1575914 for a potentially related issue.

Comment 45

[Piecevcake]

(In reply to Rob Wu [:robwu] from comment #27)

To get a better understanding of why extension developers want to run
scripts in PDF pages, please share your use case if it is not convered in
this bug or the linked duplicates.

Thanks, Rob - extension developers want to run scripts in PDF pages because firefox users like me need to use their addons in PDF pages (=exactly the same as we need to use in html pages! We need to do the same things, the only thing "special" about PDFs is they often have unintelligible names as well, which makes 2. even more necessary):

1. Page body markup- higlight, comments, stickies (eg pagemark, textmarker addons)
2. Tab annotation/highlight (eg Tab Retitle, the legacy Colorful Tabs addons)
3. Print/save annotated pages or selected areas (eg Fireshot, Singlefile addons)
4. Copy images.
5. Translation (as above).
6. Indexing (as above).
7. Accessing bookmarks (broken)
   Is that enough reasons?

Comment 46

[Zack]

(In reply to Piecevcake from comment #45)

Is that enough reasons?

I would add : sliding down page viewer using the mouse (not the scrollwheel) juste like any other PDF reader (using Scrollanywhere).
Either they could implement those functionalities directly in the PDF viewer, either they should let us use our addons.

Comment 47

[Piecevcake]

Hey fellow sufferers- you might like to upvote this bug-requesting facility to flag obnoxious and counterproductive actions taken on our reports to Mozilla!
https://bugzilla.mozilla.org/show_bug.cgi?id=1649104

Comment 48

[Rob Wu [:robwu]]

use their addons in PDF pages (=exactly the same as we need to use in html pages! We need to do the same things,
the only thing "special" about PDFs is they often have unintelligible names as well

Perhaps to a human user. To extensions, PDFs are not like HTML pages.
PDF rendering is closer to rendering an image or a video. The user can see them, but extensions have very little ability to change their behavior, except the minimal part that is available through APIs. The fact that the PDF viewer is HTML+JS is just an internal implementation detail.

Nevertheless, some of the examples (e.g. the changing title or changing the mouse behavior) are largely independent of the page's content.
Although the viewer logic itself (from PDF.js) is designed to be functional in web pages, its integration in Firefox includes extra privileges to improve its functionality (for example find bar integration).

comment 16 expressed willingness to accept a patch to allow access again. I would also accept a patch, provided that it doesn't introduce security or maintainability issues. In fact, if there are no issues at all, I would rather make this the default behavior rather than an opt-in via a pref. Bug 1436482 has a bit more of background, since this feature was disabled as a precaution in that bug.

Comment 49

[optionalrealnamenotgiven]

(In reply to Piecevcake from comment #45)

(In reply to Rob Wu [:robwu] from comment #27)

To get a better understanding of why extension developers want to run
scripts in PDF pages, please share your use case if it is not convered in
this bug or the linked duplicates.

Thanks, Rob - extension developers want to run scripts in PDF pages because firefox users like me need to use their addons in PDF pages (=exactly the same as we need to use in html pages! We need to do the same things, the only thing "special" about PDFs is they often have unintelligible names as well, which makes 2. even more necessary):

1. Page body markup- higlight, comments, stickies (eg pagemark, textmarker addons)
2. Tab annotation/highlight (eg Tab Retitle, the legacy Colorful Tabs addons)
3. Print/save annotated pages or selected areas (eg Fireshot, Singlefile addons)
4. Copy images.
5. Translation (as above).
6. Indexing (as above).
7. Accessing bookmarks (broken)
   Is that enough reasons?

Ended up here from https://pncnmnp.github.io/blogs/firefox-dark-mode.html (wanted to add a dark mode for pdf).

I was just trying to build an extension to automatically remember the last position of a pdf (I'm aware you can create bookmarks but I want something automatic) and I wasn't able because of this. It also seems people at hypothes.is are dealing with this too (https://github.com/hypothesis/browser-extension/issues/100)

Products such as Obsidian.md and many other like those rely on being able to take notes, and many of them come from browser. Annotation is more and more popular and this is a big drawback.

I hope someone can work on this feature, I'd really appreciate it.

Thank you for all the good work.

Comment 51

[clara.attermo]

This bug prevents all our customers from using Firefox.

I work at an e-signing company where we have a browser plugin for sending pdf:s to the e-signing platform.
In Chrome this works fantastic. The plugin will inject a small script that presents a small GUI and grabs the pdf via AJAX. The user clicks a button in the injected GUI to send the pdf for signing via our system. The reason we need the content script is to be able to make the AJAX call from the same domain as the pdf is on. We do not tamper with the pdf-viewer.

Please Firefox, fix this so our users can use their preferred browser.

Comment 52

[Rob Wu [:robwu]]

(In reply to clara.attermo from comment #51)

This bug prevents all our customers from using Firefox.

I work at an e-signing company where we have a browser plugin for sending pdf:s to the e-signing platform.
In Chrome this works fantastic. The plugin will inject a small script that presents a small GUI and grabs the pdf via AJAX.

The browser.windows.create API can be used to open a popup window with the dialog.
Alternatively, if the entry point of the functionality is the extension button, then you can show the UI in the browserAction panel.

The user clicks a button in the injected GUI to send the pdf for signing via our system. The reason we need the content script is to be able to make the AJAX call from the same domain as the pdf is on.

If your extension has host permissions or even an activated activeTab permission (the latter doesn't have permission warnings), then you can send the request from a background script.

We do not tamper with the pdf-viewer.

This example is a case where content-script access to the PDF viewer is not necessary.
bug 1670278 and bug 1340930 sound like more fitting features to support your scenario.

Comment 53

[paolo.caminiti]

@clara.attermo

Since firefox introduced this "feature" of forbidding extension on behalf of the user, we used to point our user to use chrome. Luckly this is not the case anymore, with both safari and edge chromium supporting extensions on pdf pages - which is wherever the user fancies - the amount of customers reporting the issue has gone down considerably as most of them will just try the default system browser.

Still it's saddening that mozilla that once did PDFjs allowing the gap between the open web and the siloed pdf format to be brdiged to some extent, is now unable to see the issue here, and the more general problem of taking decisions on behalf on the user.

You can as Rob explained open a window or a popup telling the user that in their default system browser everything is fine, hope that help :)

Comment 54

[juraj.masiar]

I've just read that Firefox 88 supports executing JavaScript in the PDF.
If a third party script can run in the PDF, does it mean it's secure now and we could enable addons content scripts as well?

Comment 55

[Rob Wu [:robwu]]

PDF scripts are executed in a sandbox, not in the viewer itself. This feature request here is about running content scripts in the viewer itself.

Comment 56

[j3.soon]

(In reply to juraj.masiar from comment #54)

I've just read that Firefox 88 supports executing JavaScript in the PDF.
If a third party script can run in the PDF, does it mean it's secure now and we could enable addons content scripts as well?

Just confirmed that this issue still exist. The content scripts still cannot be ran in the viewer, as said by Rob Wu.

Comment 57

[mk]

Unfortunately still a problem. I'd love to see an option so that users count enable or disable this behaviour in about:config

Comment 58

[Piotr Janik]

From the UX perspective it's less than comfortable. I'm using Navigate Up WE: on Chrome, it works on any page; on Firefox, it doesn't work on pages consisting only of PDFs, and it's not immediately obvious that it's supposed to be for our own good. I don't think PDFs as webpages are going to be replaced by HTMLs with embedded PDFs any time soon.

Comment 59

[Shiva Prasad]

(In reply to Rob Wu [:robwu] from comment #27)

To get a better understanding of why extension developers want to run
scripts in PDF pages, please share your use case if it is not convered in
this bug or the linked duplicates.

Hi, I need to extend the PDF viewer itself. I don't see that mentioned in any of
the duplicates. My extension would not need access to the PDF content at all,
just the viewer. Does that count as a valid use case? :)

Comment 60

[Rob Wu [:robwu]]

Re-opening this bug; I spoke to people from the PDF.js team and the WebExtensions team. If there are compelling use cases for this feature request we may reconsider, to allow extensions to run content scripts in the viewer.

Before this is feasible at all, we would have to make sure that the viewer does not have any access to privileged functionality that are unavailable to regular web content. And not just now, but also in the future.

Comment 61

[Adomas]

Zotero displays a progress dialog popup at the top right of the screen when our user saves a webpage. This has been broken on Firefox for us and we have had to resort to workarounds. We are able to display a progress dialog on other browsers and would be more than happy to bring this functionality back.

See for how this looks on other browsers: https://github.com/zotero/zotero-connectors/issues/250#issuecomment-2354675737