InformAction Forums

I am a developer on the Firefox addon "Cocoon" (https://getcocoon.com/). Our users have been complaining that our addon is incompatible with NoScript (both are privacy/security solutions for Firefox - the intersection is large!)

The reason for the incompatibility (which we cannot, unfortunately, fix on our end) has to do with NoScripts initialization process:

- During profile-after-change, NoScript processes a variety of user-set lists of URIs
- To do this, it invokes IOService's newURL (in unwrapURL - line 155 in IOUtil.js)
- If NoScript gets loaded first, these calls to IOService prevent Cocoon from initializing properly

A few potential solutions exist:

- Patch unwrapURL to not call newURI with "http" URIs (which is not required for what it does)
- Change the load order so that NoScript calls init() on final-ui-startup, instead of profile-after-change

Either way is pretty straightforward and neither is "wrong", and neither way looks like it will hamper NoScript's functionality etc.

I wish there was a way for us to fix this, but we've exhausted all our options. If y'all have an idea, let me know! I also couldn't find a version control link on the website, if SVN or GIT exists, I'm happy to submit a patch.

Cheers,

Dan Staudigel

I'm afraid it's not so simple

dstaudigel wrote: - Patch unwrapURL to not call newURI with "http" URIs (which is not required for what it does)

unwrapURL() calls newURI() whenever its argument is not a nsIURI (which, most commonly, means it was a string).
The (intended) side effect is that the return value is always a nsIURI: this is what the caller expects, so returning plain strings instead when the original value was a string starting with "http" would likely break lots of stuff.

dstaudigel wrote: - Change the load order so that NoScript calls init() on final-ui-startup, instead of [url=http://kb..org/Profile]profile[/url]-after-change

Unfortunately this is impossible as well, because NoScript needs to be fully operational before any network activity starts, and networking generally starts before UI is finalized.

May I ask you why exactly creating a HTTP URI from a string (something which surely other extensions and, under some circumstances, the browser itself can do) breaks your add-on?

Giorgio Maone wrote:I'm afraid it's not so simple

dstaudigel wrote: - Patch unwrapURL to not call newURI with "http" URIs (which is not required for what it does)

unwrapURL() calls newURI() whenever its argument is not a nsIURI (which, most commonly, means it was a string).
The (intended) side effect is that the return value is always a nsIURI: this is what the caller expects, so returning plain strings instead when the original value was a string starting with "http" would likely break lots of stuff.

If you were to create HTTP URIs using the http protocol handler directly (instead of IOService), this would not adversely affect the Cocoon plugin, and would not change any outward facing aspect of unwrapURL - you can still return nsIURI instances.

Giorgio Maone wrote:

dstaudigel wrote: - Change the load order so that NoScript calls init() on final-ui-startup, instead of [url=http://kb..org/Profile]profile[/url]-after-change

Unfortunately this is impossible as well, because NoScript needs to be fully operational before any network activity starts, and networking generally starts before UI is finalized.

Why does NoScript need to be fully operational before any network activity starts?

Thanks!

Dan

dstaudigel wrote: If you were to create HTTP URIs using the http protocol handler directly (instead of IOService), this would not adversely affect the Cocoon plugin, and would not change any outward facing aspect of unwrapURL - you can still return nsIURI instances.

I can try this way.

dstaudigel wrote: Why does NoScript need to be fully operational before any network activity starts?

ABE and HTTPS enhancements mostly, but not just that.

Okay - I've patched NoScript. The source code for it (and NoScript, unmodified) is available at github - only because I couldn't find any SCM's that you were using.

https://github.com/dts/noscript/branches

Inside the "master" branch is an unpacked NoScript with a makefile that packs it up and installed it into Firefox on MacOS.
Inside the "cocoon-compat" cranch is the patched NoScript. The diff is simple:

https://github.com/dts/noscript/compare ... pat#diff-4

I'd love for this patch to go into NoScript ASAP, let me know what the possiblity is, and what the timeline might be.

Also - I encourage you to take my noscript/master branch over for your own use (or with my patch, too!) so that you have an SCM system - which it looks like you've been planning for some time.

Cheers,

Dan

I couldn't use your patch because unwrapURL() gets called by hot code paths in NoScript, and your newURI() is significantly slower than IOS.newURI() (it takes 150% of the time on average).
It should nonetheless be fixed in latest development build, thanks.
Stable release should be out in 10-15 days.