InformAction Forums

Xenotu wrote:Same problem here.

A good temporary work around is rolling back to 2.9.5.1: https://addons.mozilla.org/en-US/firefo ... /versions/

Thank you. I did that on my desktop and now it's back to normal. I hadn't realized until I reinstalled the old one how much the new version slowed my browsing even on sites that "worked".
I really do appreciate and like no script but the new version has some kinks to work out.

What is the latest working dev build (rc version)?

Old NoScript @
https://addons.mozilla.org/addon/noscript/versions
*or*
https://noscript.net/feed?c=100&t=a

The same problem here.
Firefox 50.0.2 on Linux Mint (x86-64). Options reset didn't fix the problem, rollback to 2.9.5.1 did fix it.

It seems, that the problem has to do with how host name is determined. For instance, I click "temporarily allow site.com" in the status bar menu, the page reloads, but the scripts stay blocked, and the menu now says "temporarily allow https://site.com". A few times - not sure how exactly to reproduce, probably by opening a link a new window - I saw "temporarily allow [ site.com ]" instead.

I can verify this.

First I thought it was that Firefox needed a restart after updating NoScript, but it keeps happening repeatedly without any obvious reason.

Just adding my two cents, was updating my PC so not sure which versions came first, but I was at Firefox 50.0.2 and NoScript 2.9.5.1, working fine for internal sites on 192.168.x.x
Firefox was updated to 50.1.0 and NoScript updated at the restart of FF to 2.9.5.2, internal site stopped working.
On a hunch I checked the download page and tried the latest dev build, after which internal sites worked again.

What confuses me is that the dev build is listed as 2.9.5.2rc5, is that not a release candidate to 2.9.5.2, which I already had and did not work?

Does anyone else having this problem with 2.9.5.2 stable, *not* see the problem with 2.9.5.2rc5?

Again, what is the latest rc version which doesn't have this problem?

Split the unrelated guest post to viewtopic.php?f=7&t=22411

barbaz wrote:Does anyone else having this problem with 2.9.5.2 stable, *not* see the problem with 2.9.5.2rc5?

Again, what is the latest rc version which doesn't have this problem?

Another guest here. It's the same for me - 2.9.5.2rc5 works, 2.9.5.2 stable doesn't.

Hmm... actually, qualifying that:

2.9.5.2 stable never works
2.9.5.2rc3 through 2.9.5.2rc5 works intermittently
2.9.5.2rc2 and earlier always works.

Thank you for the detailed information, Guest.

I've just double-checked that, apart from version number, NoScript 2.9.5.2rc5 is completely identical to 2.9.5.2. Yet people are getting different results with 2.9.5.2rc5 vs 2.9.5.2. So this cannot be a NoScript issue, can it?

Odd one, this. Not sure what next for troubleshooting the real cause.

...And now, it seems, Firefox is (somehow) automatically updating NoScript from rc2 to rc5 every time I restart it. :-/

I'm wondering if there might be two bugs here - a NoScript one, introduced in rc3, that causes the behaviour this thread is complaining about, and a Firefox one that messes with the addon versioning system somehow.

Guest wrote:...And now, it seems, Firefox is (somehow) automatically updating NoScript from rc2 to rc5 every time I restart it. :-/

Tools > Add-ons Manager > NoScript > More > Automatic Updates: set to "Off"

Does this issue still occur with latest development build 2.9.5.3rc1?

Just adding my two cents: found this bug happening with youtube.com. Updated to noscript rc6, still happening.
It's adding https://www.youtube.com to the whitelist when i click allow; it appears right at the bottom of the whitelist and is the only whitelist entry prefixed with https://
Maybe if you manually add the same, a site with http:// to your whitelist you can reproduce the bug?

My hunch is the bug has two parts: not stripping https:// from the allow dialogue, cuaisng it to be added to the whitelist, and upon reading the whitelist, not properly handling such an entry.

Hope this helps

Those who are experiencing this problem, do you have e10s enabled or disabled?

If you don't know, go to about:support and post here what it says for "Multiprocess Windows".

AnonymousCoward wrote:Just adding my two cents: found this bug happening with youtube.com. Updated to noscript rc6, still happening.

What is your exact whitelist entry for youtube.com? (That is, *before* the new https:// one was added.)

When you next see this problem on youtube, can you please post here the entire script listing at that time? Right-click the NoScript Options menu item to copy the listing, then use Ctrl-V to paste.

AnonymousCoward wrote:Maybe if you manually add the same, a site with http:// to your whitelist you can reproduce the bug?

I have several whitelist entries like that, one of which I visit regularly. Still not seeing this behavior.

AnonymousCoward wrote:Hope this helps

It does help, thanks