InformAction Forums

At the moment, NoScript is acting pretty weird -- it seems that cross-domain objects are no longer blocked for some reason.

For example, the YouTube video on adblockplus.org plays for me, even though neither adblockplus.org nor youtube.com are on my whitelist.

Guest wrote:At the moment, NoScript is acting pretty weird -- it seems that cross-domain objects are no longer blocked for some reason.

For example, the YouTube video on adblockplus.org plays for me, even though neither adblockplus.org nor youtube.com are on my whitelist.

It's still blocked for me.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
NoScript 1.9.9.99 with default settings. Default theme and no other extensions.

Update NoScript to the most recent development build at http://noscript.net/getit#devel, then try these steps, in order, until NoScript is working right again.

1) If you have any Firefox extensions called HP Smart Web Printing, Skype, .NET Framework Assistant, or McAfee Site Advisor, then uninstall or disable them. They're buggy and known to cause problems with the status bar icon.

2) The NoScript settings became messed up somehow. Reset the NoScript Options by pressing Reset at the bottom of the Options dialog. Export your whitelist before doing that if you've added any trusted or untrusted sites you'd like to restore after NoScript is working again.

3) There might be an extension conflict. Use the Add-ons manager to temporarily disable any other Firefox extensions you have installed, except for NoScript.

4) Perform a Standard Diagnostic. If NoScript isn't working by the time you get to the "Create a new profile" step, a new profile with no other extensions besides NoScript should work right.

Hope this helps. Please let us know whether it does.

By the way. You need a Firefox update. We registered users can see the user agent string your browser sends. It indicates you are running an obsolete version of Firefox. It's easier to troubleshoot these issues if you're using the current version. Also, it's risky to use an old version of Firefox which has known, published, unpatched vulnerabilities. NoScript is a useful security tool, but even more effective is running with an up-to-date Firefox. Help > Check for Updates. Known Vulnerabilities in Mozilla Products

Alan Baxter wrote:By the way. You need a Firefox update. We registered users can see the user agent string your browser sends. It indicates you are running an obsolete version of Firefox.

It is 3.6.6; I edited general.useragent.extra.firefox and forgot I had done so (in retrospect, I'm not sure why).

Alan Baxter wrote:2) The NoScript settings became messed up somehow. Reset the NoScript Options by pressing Reset at the bottom of the Options dialog. Export your whitelist before doing that if you've added any trusted or untrusted sites you'd like to restore after NoScript is working again.

Exporting, resetting and re-importing the settings worked. I'm still not quite sure what happened, but thanks a lot.

You're welcome. I'm glad to hear you're using a secure version of Firefox.

Exporting, resetting and re-importing the settings worked. I'm still not quite sure what happened, but thanks a lot.

Thank goodness for that Reset button!

Ah, but alas, I spoke too soon. As soon as I restarted, the weird behavior was back.

However, I think I know what's causing it: I fiddled around with the noscript.* pref branch a bit, and it seems that noscript.cp.last is the culprit. Even with all other NS options set to the defaults, it breaks if this is set to false at Firefox startup.

Well, I think I could consider my problem solved now, but still... could you/anyone please confirm I'm not just seeing things?

Guest wrote:I fiddled around with the noscript.* pref branch a bit, and it seems that noscript.cp.last is the culprit. Even with all other NS options set to the defaults, it breaks if this is set to false at Firefox startup.

That makes sense. The default value for noscript.cp.last is true. Leave it there.

Can do. But, isn't this a bug of sorts? I've had it set to false for months, and it worked before.

Guest wrote:Can do. But, isn't this a bug of sorts? I've had it set to false for months, and it worked before.

Yes, it is a regression due to the new startup code for Gecko 2's XPCOM.
Since the actual nsIContentPolicy invocation order for noscript.cp.last=false is random (opposite to the predictable "NoScript last" for noscript.cp.last=true), I'm truly tempted to entirely remove the preference, which is likely to cause confusion or, like in this case, bugs.
May I ask you what were you using it for?

Giorgio Maone wrote:May I ask you what were you using it for?

I've been using it because of ABP. I thought cp.last=false meant "NoScript first" rather than random, but that's sort of the result; I guess ABP takes longer to initialize than NoScript.

Leaving it at true makes objects that have been blocked by NoScript appear in the blockable items panel. It just seemed "wrong" to me, I guess I've been using it as a "loaded URLs" panel. I also figured there must be a small performance gain of having NoScript go first (i.e., checking the URL against comparatively small list of domains first before matching it with thousands of patterns).

Oh, and also this seems to upset NS surrogate scripts (i.e., they don't run if the URL is also blocked by ABP).