appAPI.ready() does not fire on select pages on Firefox

Edit Subject

Hello Blair,

Thank you for reporting this issue. We will investigate and get back to you next week.

Hello Blair,

Currently, we have determined that there is an issue with your code using new Function which appears to be an issue on github's site. It's not something that can be fixed quickly as it requires a deep look into the cause of the issue, and hence not likely to be resolved in the near future due to other project requirements.

Hence, it would be helpful if you could identify where in your code the new Function is in use and perhaps workaround the issue by using eval or $.globalEval. Also, if you do determine the cause, please report back to us and we'll be happy to test and fix if required.

When you say there is a problem using new Function, do you mean there's a problem instantiating ANY object, or is it specific to a new Crossrider instance?

The extension seems to fail before we ever call new, since appAPI never fires .ready().

Hello Blair,

Thanx for the update ... I will look into this further and get back to you.

Hello Shlomo, we are seeing a similar problem in which the extension does not seem to activate (i.e. appAPI.ready does not fire) on a https://github.com/login page on Firefox (25.0.1, running on OS X Mountain Lion) at all.

The following information may help your team debug this.

Github login page sets the following Content Security Policy (CSP) header:

x-content-security-policy: default-src *; script-src 'self' https://github.global.ssl.fastly.net https://ssl.google-analytics.com https://collector-cdn.github.com https://analytics.githubapp.com https://embed.github.com https://raw.github.com; style-src 'self' 'unsafe-inline' https://github.global.ssl.fastly.net; object-src 'self' https://github.global.ssl.fastly.net

This CSP corresponds to disallowing scripts from any source other than listed in the header.

And as a result, Firebug shows the following error on the console, triggering somewhere deep in the Crossrider framework code:

Content Security Policy: Directive inline script base restriction violated

window.script1385508035566=1;

Relevant CSP documentation is here: https://developer.mozilla.org/en-US/d...

I too confirmed that appAPI.ready(function ($) {..} in extension.js never fires when on https://github.com/login page. Most likely this is because the extension framework is trying to execute code (such as new Function()) that is disallowed by the CSP of this site, as explained in my previous comment. I determined this by stepping through the code.

@Shlomo, has your dev team found anything since Blair reported it? We are desperately looking for a workaround.

Hello Gupta:

We are working on this issue and hope to release a fix in the coming weeks.

@Shlomo, any idea how this is going?

Hello Sujoy,

I've requested an update from the Dev team and will update you, probably on Sunday.

Hello Sujoy,

This is still an ongoing project which we will release once it completed and passes QA.

@Shlomo, thanks for the update.

Any sense of the timeline when you think the fix might be available?

Hello Sujoy,

This is a complex change that requires a lot of testing to pass QA. Hence the dev cycle is extensive. All being well, we hope to have a fix in place early next year.

@Shlomo: Has this been fixed? I am still seeing this problem on Firefox and GitHub.

Hello Sujoy,

As mentioned, it's a complex matter and so far it hasn't made it through QA.

However, we have found that code outside of appAPI.ready does run hence you can try coding your extension in this way. Bear in mind, if you use any resources, you will have to add an additional check to determine they have loaded as, depending on the size and number of resources, it can take a short while to load them (usually a second or two).

Let me know if you require any assistance with this.

@Shlomo, running code outside of appAPI.ready is not an option since we have seen that on some browsers, the functions and variables defined outside of appAPI.ready are not accessible inside it.

It's been a while since this problem was reported. I understand that it must be a complex fix and that the framework is free and as-is. Yet, since our product depends critically on it, it'll be great to know if there is an expected timeline for the fix.

Thanks.

Hello Sujoy,

Thank you for the additional information and I appreciate your position.

Like you, we would love to fix this issue and we have tried several solutions to date that have not passed QA as they break other features of the framework. As previously mentioned, it's a complex matter and one that is not likely to be resolved in the near future, unless one of our continuing attempts succeed.

@Shlomo, it has been 8 months since this issue was reported. Could you please share how this is progressing?

Hello Sujoy,

Thanks for your update request.

The issue relates to the specific way which these sites are implemented and currently, we do not have a reliable solution or work around for it. Should you discover one, please feel free to share and if it can be implemented in our framework, we'd be happy to do so for the benefit of all users.

Hello Shlomo,

I am happy to help as I have in the past with the appAPI.message.toAllTabs issue.

Could you share what you have found so far about the specific ways in which these sites have been implemented that is different? That will help me get to the bottom of the issue faster for the benefit of everyone.

Hello Sujoy,

Please email support@crossrider.com.

Hi,

I am trying to understand if I am having the same (not yet solved?) issue. When running my extension in Firefox on a GitHub page (not login, already inside the app), it fails to fire the appAPI.ready event, and the following errors appear in the console:

Content Security Policy: The page's settings blocked the loading of a resource: An attempt to execute inline scripts has been blocked issues

Content Security Policy: The page's settings blocked the loading of a resource: An attempt to call JavaScript from a string (by calling a function like eval) has been blocked

Is this the same problem? Or a different one?

I do not have any “eval”s in my code, so I guess this is the way Crossrider wraps the user code in the extension? Your discussion above doesn't look very encouraging, I hope there is a way to work around this limitation somehow (could we try to change the CSP settings in FF for the page? Or at least suggest users to turn something off somewhere? Just ideas, I didn't try anything yet.

Thanks in advance!

Hello Anton,

It sounds like you are experiencing the same issue and currently there is no working solution for this. In general, it's an issue with the way Firefox implements it's sandbox environment that conflicts with running user code in the sandbox on certain sites.

OK, so what I found so far.

Here's GitHub announcing their side of the change (Apr 2013), saying it shouldn't affect extensions, yet that it will probably cause issues for quite a few: https://github.com/blog/1477-content-...

Here's a lengthy discussion about the corresponding Firefox bug https://bugzilla.mozilla.org/show_bug..., still unresolved, and in May 2014 someone created a follow up request in https://bugzilla.mozilla.org/show_bug... (Allow user to override CSP by supplying a list of always-allow domains). Also not implemented yet.

There is a “UserCSP” Firefox addon which could some sort of a solution (to use alongside with Crossrider in FF — would allow to set user-specific CSP rules to override those set by GitHub) https://blog.mozilla.org/tanvi/2012/0... — yet it looks very outdated, I can't even find a way to invoke its UI (https://github.com/patilkr/userCSP/is...).

Yet this addon's source is available online, https://github.com/patilkr/userCSP/, may be Crossrider development team could take a look at it and see how incorporate similar (optional) CSP-elevation logic in the Crossrider framework?

Unfortunately, from what I tried, Crossrider can't claim to work on Firefox right now — some very basic things may work, yet not much. Of course I may be biased by what my extension needs, and for other purposes it may be okay.

Hello Anton,

Thanks for your feedback. I have forwarded you findings to the dev team to review and, if relevant, to try implementing a solution though it may take some time as it's not a trivial matter and must pass QA.

Your feedback is much appreciated.

Alright, the author of UserCSP (the Firefox plugin which allows configuring custom CSP rules per site) updated their plugin to work on FF 30.0, and uploaded it their GitHub repository (he responded to me here https://github.com/patilkr/userCSP/is...), and pushed the update to addons.mozilla.org (it will be published when approved).

I tested it with switching github.com to use “User Policy”, which basically means override the site's rules completely and allow everything (unsafe, yes, but I wanted to see if it helps) — and my addon works! appAPI.ready fires, AJAX requests work and return data, etc.

So while this is not very practical to recommend to all users (they just won't install another addon), still it is a practical workaround (say, if you have a specific customer who needs to run your addon in Firefox), and I do hope that Crossrider team will be able to use this information to make necessary changes so that there is no need for UserCSP installed at all.