InformAction Forums

latest development build is out:

v 1.9.4.2
=====================================================================
x Fixed mixed content SSL false positives when ABE enabled
x Fixed file:// entry added to whitelist everytime a 2nd level
domain gets allowed on Gecko >= 1.9 (thanks GµårÐïåñ for reporting)

@therube: the "broken icon" was just a cosmetic artifact, security of the page was not broken.

@dhown: that bug is fixed as well, even though not reported in the changelog, because of the SSL mixed content fix.

@GµårÐïåñ:
the file:// issue has been quite hard to track, because it was actually not a bug freshly introduced NoScript, but a behavior change in Gecko's nsFileProtocol class: file URLs don't seem to support hostPort anymore (it was used to address Samba shares), and this caused any 2nd level domain to collapse into file:// as soon as it was added to the whitelist.

Giorgio Maone wrote:

Code: Select all

Site googleapis.com *.googleapis.com
Accept from site1.com site2.com
Deny

Thank you sir, figured that but thanks for confirming.

Yes, a rule builder is definitely in the ABE roadmap, but if you build your wizard in XUL (or XHTML) + JavaScript, maybe we can reuse something in ABE's core

I will try to make it in XUL but at the moment its VB.NET but once I get it working, I can easily port it and you are most welcome to ANY useful portion of it. Definitely.

I have discovered an issue with the latest dev build that many sites that I have gone to have had trouble logging in (loops back to login screen like the data is not kept) and logouts that just hang or come back with :neterror message (connection just drops and won't acknowledge again, must restart Fx). I observed that the sites that it was happening on, were operating ASP.net with javascript:dopostback methods on everything. These tend to be the ones failing to log on to or log out from. Why is this happening? If I disable NS AND reboot Fx, then I can go with no problems on any of them. If I disable NS WITHOUT rebooting Fx, it will not work either BUT rebooting Fx fixes it in disabled mode.

GµårÐïåñ wrote:I have discovered an issue with the latest dev build that many sites that I have gone to have had trouble logging in (loops back to login screen like the data is not kept) and logouts that just hang or come back with :neterror message (connection just drops and won't acknowledge again, must restart Fx).

Can you pinpoint a reproducible case for me?

GµårÐïåñ wrote:If I disable NS WITHOUT rebooting Fx, it will not work either BUT rebooting Fx fixes it in disabled mode.

That's not suprising, since disabling an extension from the Add-ons Manager require restarting Firefox for being effective.

1.9.4.3 Dev

x Optimized garbage collection in DNS 2nd level cache

And that could be contributing to "high memory usage".

(Which is very difficult to quantify, though suffice to say it appears that I've been running into higher Mem Usage <&VM Size> numbers then I would be expecting when running the last number of builds. Matter of fact, first thing I did this morning was to open Task Manager.)

Ah, who knows.
Unresponsive Script Warning (with high CPU usage during the time).
At some point after the fact: And while we're here: Don't know if any of this relates or will be meaningful?


Anyhow, Mem Usage seem much more controlled.

therube wrote: Unresponsive Script Warning (with high CPU usage during the time).

Where exactly, and which message (those warnings have a file and line number, usually)?

I'm not really sure.
What I posted looked to be the most "useful" & what I posted is all that was shown (for those particular messages).

therube wrote:

x Optimized garbage collection in DNS 2nd level cache

And that could be contributing to "high memory usage".

(Which is very difficult to quantify, though suffice to say it appears that I've been running into higher Mem Usage <&VM Size> numbers then I would be expecting when running the last number of builds.

I installed 1.9.4.3 a couple of hours ago. Mem Usage and VM size still relatively low, although I haven't browsed much since the restart.

Matter of fact, first thing I did this morning was to open Task Manager.)

Mine's in my Startup folder.

Anyhow, Mem Usage seem much more controlled.

Maybe. Maybe not.
Real difficult to determine. Really hard to pin it on NoScript (or anything in particular).
Seemed to start out better. Right now I'm sitting at 300 MB Mem, 376 MB VM? I would have expected (whatever that means) less.

Giorgio Maone wrote:Can you pinpoint a reproducible case for me?

Nothing that you would be able to log into, I will see if I can find something that will reproduce this for you.

That's not suprising, since disabling an extension from the Add-ons Manager require restarting Firefox for being effective.

Of course but in the case of NoScript, if you disable it via (allow globally) then it should relinquish but it doesn't until you reboot. That's what I mean by disable, not actually disabled the addon. If I tell NS to allow globally it will not work until I reboot Fx which is totally and should be unnecessary.

GµårÐïåñ wrote:Of course but in the case of NoScript, if you disable it via (allow globally) then it should relinquish but it doesn't until you reboot. That's what I mean by disable, not actually disabled the addon. If I tell NS to allow globally it will not work until I reboot Fx which is totally and should be unnecessary.

This might have been true long time ago, when all NoScript did was "allowing" and "forbidding".
Now you got many stuff like XSS protection, HTTPS enhancements, Clearclick or ABE which are still active even if you "Allow scripts globally", and have their own preferences to be disabled.

Giorgio Maone wrote:This might have been true long time ago, when all NoScript did was "allowing" and "forbidding".
Now you got many stuff like XSS protection, HTTPS enhancements, Clearclick or ABE which are still active even if you "Allow scripts globally", and have their own preferences to be disabled.

Understood, of course but as I said restarting with NS in globally allow makes it work fine, so although it might be faulty logic on my part, I am assuming the issue is not the with the remaining components that remain active. UNLESS, whatever issue exists IS indeed caused by the XSS and other still active components, just exasperated by the regular NS functionality. So there is that too but no way to know I guess. I was hoping you would work your magic and see what's up. I updated to the 1.9.4.3 dev as well and agree with therube that on certain occasions, there is a huge performance drag, which I actually reported in my initial post but everyone told me they couldn't reproduce it, so I let it go.

EDIT: So far the easiest and quickest site that can reproduce the login issue is Netflix. 1) Log in here: https://www.netflix.com/Login and 2) It will refresh to this page: http://www.netflix.com/ consistently each and every time. Effectively no access with NS and coincidentally now NS needs to be disabled on the addon level, no longer will globally with reboot fix the issue. Bummer.

GµårÐïåñ wrote:So far the easiest and quickest site that can reproduce the login issue is Netflix.

I've just signed up for the 2 weeks free trial, giving fake generalities (I don't live in US but they want a valid address wich they validate up to the suite number ) but real credit card details , however I couldn't reproduce this issue: I can login just fine on Netflix (ABE enabled, automatic secure cookies enabled, XSS enabled, scripts disabled but on netflix.com, all the usual suspects invited...)

I know it may sound lame to you, but could you try Alan's standard troubleshooting (starting with an export/reset)?

Giorgio Maone wrote:I've just signed up for the 2 weeks free trial, giving fake generalities (I don't live in US but they want a valid address wich they validate up to the suite number ) but real credit card details , however I couldn't reproduce this issue: I can login just fine on Netflix (ABE enabled, automatic secure cookies enabled, XSS enabled, scripts disabled but on netflix.com, all the usual suspects invited...)

I know it may sound lame to you, but could you try Alan's standard troubleshooting (starting with an export/reset)?

I am sorry you had to go through that, I am sorry. If you want you can give me the account and I will change the credit card on it and take over until it expires. I don't think its lame and I have done that 3 times already thinking the same thing, I don't even care about my white/blacklists I recreate, I do it regularly anyway to keep the list optimized. Given how much dev testing I do with unstable versions, it comes as the hazards of the job I don't know what the heck is going on then.

Update: I noticed the only difference between your conditions and mine was that you had scripts disabled. So I figured, maybe something to that. I logged on with scripts disabled and it comes up with the url: https://www.netflix.com/redirect.jsp?ta ... lix.com%2F and a meta-redirect message with this info: <meta http-equiv="refresh" content="0; URL=http://www.netflix.com/"> and goes to the main page. Frustrated, I tried logging in again and HOLLY SHIT, it logs into the MemberHome this time around; HOWEVER, the path in the url is the same as above and the meta forward is listed same as above but it lands on the http://www.netflix.com/MemberHome so what the hell? In addition, notice that login page is HTTPS but when it forwards or lands on member home, its HTTP. Is there something screwy going on with cookie management? Now enable scripts for Netflix and sure as shit, it will keep looping into the login, home, login, home and never lands on the memberhome, this is becoming a real perpetual pain in my *BLEEP*

Update2: Now as if that wasn't bizarre enough already, allowed the site to see if I could reproduce the issue I had earlier and I get this lovely looking thing on reload after allowing script: