Tranform HTTP urls to HTTPS to honour the CSP

[cipri-tom]

Hello,

Using HTTP urls results in an empty page, because the content cannot be loaded due to CSP violation.

Why are you using HTTP urls ?

When using http://www.arxiv-sanity.com/ , the PDF link is in HTTP.

Then arXiv-sanity should upgrade to put HTTPS links

That's what I thought. However, they are getting the URL straight from the arXiv API response, e.g. this ling gives an XML where we can see they refer to the link in HTTP :(

Also, the HTTP link doesn't result on malfunction on their end.

[j3soon]

@cipri-tom Thank you for the fix! I'll upload this in the v1.5 Firefox release.

btw, the Q&A style description is really informative. ;)

[cipri-tom]

Thanks for accepting the PR !
I really hope that it works 😬 . I could not test it locally 😞 . I was hoping I can modify the extension's files in Firefox's directory without having to build, but that didn't work.

[j3soon]

Just finished testing and updated the extension to v1.5! Your code is confirmed to be bug-free. ;)
btw, there is no need to compile for testing the extensions locally:

1. Go to Firefox's Extensions Page (visit url about:addons or from the menu Tools > Add-ons)
2. Click the gear icon located at the top left, and click Debug Add-ons (or directly visit url about:debugging#/runtime/this-firefox)
3. Click Load Temporary Add-on... and select an arbitrary file located in arxiv-utils/firefox/. (Or you can zip the folder and select the compressed file)

The extension is now loaded and can be tested locally! (You should disable the store version arxiv-utils to avoid extension conflict)

[cipri-tom]

Awesome !

Thanks for the tip, I didn't know I can load an unpackaged extension. It works and my sanity is restored 😁

By the way, I have just noticed that you have you maintain two separate versions for Firefox and Chrome :( . They seem almost identical, so I'm curious why you opted to keep them separate.

Cheers!

[j3soon]

Yes, maintaining the 2 separated versions are quite painful. However, this is necessary since Firefox has strict restrictions on PDF.js. The restriction disables any extension when viewing a PDF file, so arxiv-utils cannot directly modify the tab title of the browser-embedded file.

My current hacky solution is to force redirect any PDF URLs into a custom extension page, which has an embedded PDF.js object in it, showing the content of the PDF file. This solution allows arxiv-utils to have the privilege to run any scripts on the page.

So, if you are viewing a PDF in firefox with arxiv-utils installed, you'll see the URL be changed into something like moz-extension://..., this is the container mentioned above. Arxiv-utils will also intercept the bookmarking signal to ensure if the user bookmarks the container URL, the URL will be changed into the original PDF URL.

[j3soon]

I've just thought of a possibility to merge them!

It may be possible to simply disable the container code segments in Chrome, using the method like this and this. Maybe I'll use these techniques to tidy up the code base in the near future~ Thanks for the advice! :)

[cipri-tom]

Thank you for the explanation about the inner-workings !

I had suggested some time ago in a private email that this container method could be a more general workaround for firefox's disabling of extensions in PDF pages. Maybe at the same time you could revisit that idea :).

Many thanks again !