Issues in Firefox PDF container

[j3soon]

• After clicking on links in PDF (e.g. reference links), cannot use Go Back button to navigate back to the link's position.
• Cannot use Firefox screenshot tool

(Issues reported by Rick Tu)

[cipri-tom]

Yeah, I've also noticed the back bug since the beginning. Now I have an idea: I think it happens because the PDF is rendered in an iframe.

So, we have to catch the actions on the page (back, forward) and send them to the iFrame. Not 100% sure how to catch them, though. The history API is mostly concerned with, well history, and since there is no history in the window, I don't think these events will be fired 😑. Unless we can insert an artificial "zeroth" frame, then load the document. This way, Back action becomes possible, then we catch it, and override it to send to the iFrame, where the local PDF viewer will do the magic.

What do you think ?

[j3soon]

I'm not sure if web extension API supports those operations, but I think it may be worth investigating. I'll see if I can try implement it in my free time. 🙂

[j3soon]

The current approach of wrapping PDFs in iframe cannot fix this easily, see this post.

Instead of viewing the PDF inside an iframe, directly including the source of PDF.js through a CDN may be a more promising/flexible approach. (suggested by Rick Tu)

[cipri-tom]

Gosh, this is really difficult ! I tried to look up how to include it from CDN, but it seems that then we can only refer to files from the same domain: https://github.com/mozilla/pdf.js/wiki/Viewer-options#options-after-the--1

I tried to gain access to the iframe's contentWindow.history, but CSP is blocking it. I tried to modify CSP to be more permissive on our side, using script-src 'self' https://arxiv.org https://export.arxiv.org https: data: 'unsafe-inline'; in the manifest, but it doesn't work. I believe it's the CSP of PDF.js that is blocking it.

Do you know of a more flexible CSP ?

Or, if we do include it from CDN, I don't get why we are restricted to file=... to be on the same server. We could have a CSP that allows other servers, couldn't we? (arXiv)

Finally, it remains to include it directly in the extension. But then we have to keep upgrading the extension every time Mozilla upgrades PDFjs, which I think is a No-Go :(.

Thanks for your insight !

P.S. Nice work in RL !

---

Edit:

It turns out that loading from a CDN actually works with arXiv documents. I have modified the extension to load the pdfJS source from CDN, and to render the article from arXiv. The downside is that if we want the full power of native pdf.js, we still need to include a few of their scripts in the extension, notably the viewer. So far I have used simpleviewer.(html | js) , but this doesn't include buttons for rescaling, nor sidebar, or other options:

The developer do not encourage re-using the same viewer as the original: mozilla/pdf.js#13928

What do you think we should do next ?

[j3soon]

Thanks for spending time investigating this issue!

Similar to what you have mentioned, the developers have discouraged the reuse of the viewer to avoid confusion in bug reporting. (mozilla/pdf.js#8513)

However, I prefer using the same viewer as the original one, since the buttons and sidebars are important features. We can still respect the developers' suggestions by slightly modifying the top bar and adding some text, such as (arxiv-utils custom build).

[j3soon]

Fixed in 5a624f6. The fix will be included in the v1.7.2 release.

[j3soon]

Usage: Go to about:addons, select arxiv-utils, and click the Update button in the experimental section.

[cipri-tom]

Super nice to see this integrated ! Thanks a bunch for doing it, and doing it so simply !

(and for the credit too 😳)

I tested it yesterday and today, and it mostly works. However, I have come across a use case where it does not work: https://arxiv.org/abs/2212.14052 . It seems that the PDF link does not contain the .pdf extension, and Firefox's viewer does not know how to open it. If, however, we click on PDF without the extension (or in a different browser), the arXiv server issues a 302 redirect to the link with .pdf added, which is then correctly opened.

Since the link is directly appended to the file= parameter, this redirect does not happen. Maybe we should raise the question with Firefox so ask them to follow redirects, but until then, an easy fix might be to append ourselves the .pdf if it's not there. What do you think?

[j3soon]

Thanks for testing this experimental feature and investigating the issue! (This experimental feature is made possible thanks to your in-depth investigation and practical solutions in #13)

I just confirmed the issue: Clicking the extension action button on the abstract page works well. However, clicking the Download: PDF link shows a empty pdf.js viewer for most papers.

I don't think the 302 redirect issue is a mozilla/pdf.js issue, since the PDF viewer should only be triggered after the 302 redirect.

Adding a trailing .pdf does not work for some special URLs. Therefore, the natural fix is to only open the PDF viewer after the browser handles the 302 redirect.

This issue should be fixed in e30fb1f. I haven't publish the fix to the firefox store yet, you can try it out by cloning the master branch.

Please tell me if there are any further issues. Thank you!

[cipri-tom]

Thank you for the quick resolution !

Yes, the master branch seems to work on the papers that I have open. I haven't done in-depth tests.

Thanks!