InformAction Forums

If we are at it, it could be also written as: etc.

Looks nicer, IMHO.

Thank you Giorgio, I appreciate that. So if you use a value say (8192) it logs EVERYTHING. But if say you use (32) it will log everything from the beginning to that point and not the rest, right? We don't have to actually add the values or increment do we? Just making sure, since I see you are using Constants in a sort of enum, wanted to make sure they are not individual but rather inclusive.

> const LOG_CONTENT_CALL = 1 << 1;

But not everyone will understand the meaning of that notation.
(I don't, but gather it is a bitwise manipulation.)

> So if you use a value say (8192) it logs EVERYTHING
> But if say you use (32) it will log everything from the beginning to that point and not the rest, right?

No & no.
8192 will only log ABE & 32 will only log Injection.

> We don't have to actually add the values or increment do we?

Yes.
1 + 2 + 4 + 8 (so a total of 15; noscript.consoleDump=15) will give you the first 4 items (block, call, intercept, chrome)
1 + 4 (so a total of 5; noscript.consoleDump=5) will give you (only) block & intercept

Bit field

Bit manipulation

A Quick Bitmask HOWTO for Programmers

@therube, thank you for that. I guess I wasn't clear, I am familiar with how bitwise calculations are done, I just wanted to make sure whether he is using the traditional which will have to be stacked as you put it so well, or its all inclusive to lessen the chance of mistakes by less familiar users. That's the clarification I was going for, otherwise, I am familiar with the standards of bitmask/bit manipulations, thank you Its always good to see you doing your thing though, its awesome, good job and keep it up.

Giorgio, have you noticed the MASSIVE amount of CPU consumption and a major performance degradation when you enable ANY of these logging items? Especially if you stack them to include say all of them. I noticed that even with ONE of them it consumes quiet a bit of resources and slows WAY down but anything more than that and it becomes nearly unusable. Just saying to see if you know the exact performance cost of this or have it benchmarked?

This is a highly interesting and informative thread, indeed!

And this is an opportunity to point out that jimoe's problem is probably common to particularly (but not only) Noscript newbies. I guess for many NS users it's hard to tell what exactly is responsible if something doesn't work as expected: blocked scripts, blocked plugins, HTTPS settings, XSS or ABE rules. Okay, we have the Firefox error console, and we can start FF with -Console option as we learnt in this thread.

But let's face it: For most users this is much too complicated and user-unfriendly, and I think this is one major reason why many users give up with Noscript. A logging function available from the NS menu which clearly indicates what exactly NS is blocking is therefore highly desirable. I realize that this would surely blow up the NS code, and it might also increase CPU consumption as GµårÐïåñ suggests. I have no idea if Giorgio can solve this problem - perhaps this logging function should only be enabled on request. But I'm sure that for many users this would make life a lot easier, and it would surely improve the acceptance of Noscript in general.

Giorgio, what do you think about this?

Hi folks,

I've recently noticed NoScript logging (a lot) to the console where it didn't before. I'm using 2.1.1.2rc5 with Firefox 4.0.1 on Arch Linux.

about:config shows Changing noscript.consoleLog to true reduces the output to one entry per page visited, such as Is there any way to de-activate all output?

Many thanks.

Please get rc6 from http://noscript.net/getit#devel or switch back to stable 2.1.1.1

Giorgio Maone wrote:Please get rc6 from http://noscript.net/getit#devel or switch back to stable 2.1.1.1

Wow, that was a quick reply! Many thanks for all your hard work.

EDIT: Yes, rc6 is silent

Yes we monitor and Giorgio is a master at being on top of it. As for the suggestion to add some type of logging on demand for support purposes is something that I would support. Although the UI-less implementation (as in right now) is sufficient for most cases, but a possible support tab with the option to select the level of logging and even possibly a location to store it like a text file on the desktop or something so it can be attached is something that I think is worth looking into to reduce the amount of back and forth in getting the information needed to debug an issue. Thank you for your input.