Add-on not working on raw.githubusercontent.com/* and other pages using CSP `sandbox` directive

[dufferzafar]

I installed the addon and opened this URL but it doesn't get highlighted.

Are there any more changes that I need to make?

[Qeole]

Hi @dufferzafar,

Thanks for reporting the issue!

I think I encountered this problem before. I checked again yesterday, and I can't use the add-on either on your URL (or at any page under https://raw.githubusercontent.com, for the record). The logs tell me that “host permission [is] missing for the tab”, which I don't really explain.

On the same page, it seems that I have other add-ons that do not work as expected (e.g. Saka Key does nothing). I wonder if add-on permissions could have been deactivated for those pages in Firefox, but I've seen nothing about that anywhere, so that would be surprising.

Will keep investigating, and I'll report here if I find anything. In the meantime, I'm afraid I don't have any workaround for you :-(.

[Minothor]

Having this same issue on raw.github for a JS file (written to ES6 spec)
I've tried manually selecting JS from the dropdown but nothing changes, still the same black text on a white bg.

Installed on FireFox 61.0.1 (64-bit) running on Pop! OS, built off Ubuntu 18.0.4 LTS

[Qeole]

Hi Minothor, thanks for your feedback!

I made some more research today and I found the answer at last, on StackOverflow. TL;DR: Replies from this domain include a specific header that some browsers, including Firefox, interpret as a directive to NOT load a script on the page. I have yet to search the Bugzilla tickets to figure out if a workaround has been proposed.

[Minothor]

Hi Qeole, cheers for the update and that's a pity, understandable if Firefox are implementing the CSP restrictions that strictly but still a pity. Your extension was fantastic for exactly that purpose (made viewing raw files more intuitive than GitHub's own highlighting when their syntax detection failed)

[Minothor]

Hi @Qeole, one of my colleagues recently introduced me to an extension that is somehow able to work with GitHub's page content despite firefox's strict CSP implementation.

The installation permissions are very specific to GitHub pages though.
Might there be a solution there perhaps?
https://octolinker.github.io/

Edit: The manifest file also lists various GitHub URLs explicitly:
https://github.com/OctoLinker/OctoLinker/blob/master/assets/manifest.json

[Qeole]

@Minothor Thanks! I'll have a look at it. On a short glance to the manifest.json (thanks for the direct link!), they have permissions on github.com and gist.github.com, but I see nothing about raw.githubusercontent.com, which is the issue here. The add-on I use to get navigation shortcuts (Saka Key) works well on both github.com and gist.github.com, so I don't think replies from those domains embed CSP headers. Did you manage to use OctoLinker successfully on a plain text document at raw.githubusercontent.com? If so, I can look further into it. Otherwise, I'm not really optimistic.

[Minothor]

Hi @Qeole
You were right not to be optimistic I'm afraid, I tried out octolinker on raw.githubusercontent.comover the weekend and no joy.
I've also compared the headers of the two and raw.github... doesn't send any CSP rule, just a COR rule for any domain.

I also tried out the addition of the url to permissions in a local clone (cheers for inadvertantly introducing me to web-ext btw!) but no joy.

[m1ndk]

Hello everyone. I installed Enlight mostly for raw.githubusercontent.com and it's really unfortunate that it doesn't work. The first page I loaded when the plugin was installed was wal.vim and as soon as I hit autodetect it started working. Then I proceeded testing all the colourschemes to find a suitable one and there I noticed that some schemes had whitespace around the code while others coloured the whole page and made it look perfect. I have successfully reproduced this issue many times :
working + whitespace VS working perfectly
Sometimes it happens when it's the first time the page is loaded and refreshing it solves the issue. The easiest way to reproduce the same outcome (although there were times that it required more efforts) is to go to another firefox window and load it there too (doesn't seem to matter if you leave the first one open or not). Besides all that, any idea why is the only one working? This clearly breaks the "or at any page under https://raw.githubusercontent.com, for the record" statement. I have tried java,C,html,css,json,js,python,bash and had no luck at all. I really hope this addon won't be left for dead.

[Qeole]

Hi @m1ndk, thanks a lot for your feedback!

So regarding the pages on raw.githubusercontent.com, there are details about this on StackOverflow, short version: when sending those pages, the GitHub server sends a specific header that enforces a kind of sandbox for the page, preventing (among other things) the add-ons to inject what we call “content scripts”. So Enlight cannot inject the script that usually does the syntax highlighting in those page. However, there seems to be an option in Firefox that can be deactivated. Could you tell me what value you have for security.csp.enable, accessible on the about:config page? It seems to be at true by default, but setting it to false disables the Content-Security-Policy and makes Enlight work on raw.githubusercontent.com. I cannot tell what the other consequences in terms of security are, though.

Regarding the white border that pops in sometimes, I'm aware of this and consider it a minor issue, here is why it happens:

1. When the script is loaded into the page, it loads a CSS stylesheet.
2. It takes the raw text and puts it in a <pre></pre> HTML block.
3. Magic happens, the code is parsed and gets various CSS classes on the keywords, so that all the code gets coloured as expected. The background for the <pre> object also gets coloured.

At this step, you have the result that you can see on your first picture, the one with the whitespace all around. This is because the highlight.js script and related CSS sheets do not change the background colour for the HTML <body> element (parent to the <pre> block). So the add-on performs a last step:

4. The script picks the background colour of the <pre> object and also applies it to the <body> element.

But to do that I must have the <pre> block coloured already, so I need the asynchronous highlight.js script to have finished his job. So the change of background colour for the <body> only happens after a timeout. Depending on the size of the document, this timeout is sometimes too short and the change of colour happens before syntax highlighting has been performed, so the background colour change fails and we keep this white border. As you noticed, reloading the page relies on the cache and things go faster, so updating the border usually works in that case.

Of course I could increase the duration of the timeout, but it would make a nasty visual effect where the page gets coloured in two steps, first the content and then the border. I tried several values and the current one seemed to work for me in most cases. If this is really an issue for you, I guess we could make the duration an option eventually. If you think it's not worth it, I'll probably leave it as is. I don't have a good workaround in mind to avoid relying on this timeout at the moment.

Hope this helps? Let me know if you have further questions. And I'm very interested in the value you have for that option, I would be extremely surprised if you had CSP activated and the add-on working!

[omeid]

Here is the relevant Firefox BZ: https://bugzilla.mozilla.org/show_bug.cgi?id=1411641

[Qeole]

Thanks for the link!