InformAction Forums

NoScript interface stopped to work last week ( empty preferences , empty menu & context menu ) after updating my Mindfield installation, but all preferences , site preferences , otpions were mantained since the status bar icon correctly showed the site blocked or allowed.

After updating NoScript to the latest dev version the options' window returned to be populated correctly with all the fields ( whitelist , script options , ABE, etc ) but the context menu is still not working since it shows always the same options like in the pic , independently of the options selected.

It was so while I still was on Hardy , the same now on Lucid ( I've also updated the xorg package to eventually avoid the X crash BUG )

It's working for me, same build as yours (Mozilla/5.0 (Windows; U; Windows NT 5.2; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100513 Minefield/3.7a5pre).
Can you turn the javascript.options.showInConsole about:config preference to true and check whether any error message appears in Tools|Error Console when you open the menu?

linuser wrote:

Code: Select all

Error: missing argument 0 when calling function Array.slice.apply
Source File: chrome://noscript/content/noscriptOverlay.js
Line: 798

Thanks for the info, which hints at a bug related to a specific configuration: you've got the "Blocked Objects" menu hidden in NoScript Options|Appearance and NoScript Options|Advanced|External Filters enabled.
I'm fixing that. As a work-around, you should either show the "Blocked Objects" menu or disable the external filters.

[EDIT]
The problem appears to happen anyway if external filters are enabled, but on Minefield only
Further investigations needed...

I think I've got it !

The problem is maybe caused by AdBlock Plus, because I have also this extension in my working profile.

I've tried to install Noscript in a fresh profile : the same message in the js error console but the menu worked correctly.

Then I've imported the same preferences of my working profile : the same error message in the console but the menu still worked.

I've installed AdBlock Plus : the same error message in the console but the menu behaviour is now the same as reported in the first post.

OK, found the culprit.
Looks like, in recent Minefield builds, Array.slice.[call|apply] (the generic method) has a different behavior than Array.prototype.slice.[call|apply]: This is not a bug, but rather an edge behavior (the generic methods are meant to be called directly, rather than using call/apply) which has been removed, intentionally or not, from recent builds.
I'm gonna fix it by using the "natural" syntax for generic Array methods, i.e.

I am curious about Array.slice(). Isn't slice an instance method, inherited from Array.prototype? Then Array.slice() shouldn't even exist. Why does it? and why do you use it?

If it does exist and is a function, then how could it not inherit call and apply?

al_9x wrote:I am curious about Array.slice(). Isn't slice an instance method, inherited from Array.prototype? Then Array.slice() shouldn't even exist. Why does it? and why do you use it?

https://developer.mozilla.org/en/New_in ... g_generics

At a certain point (when I dropped Firefox 1.0.x compatibility) I converted all my usages of Array.prototype.method.call() to Array.method(), for convenience and speed (it spares at least one property access). Unfortunately, some instances of the replacements were hybrid, i.e. Array.method.call() rather than directly Array.method(), but everything still worked because, as you said, you could logically expect call() and apply() to work the way they are currently working on Firefox 3.6.3

al_9x wrote: If it does exist and is a function, then how could it not inherit call and apply?

It does inherit both call and apply, they're just not behaving anymore (in Minefield) the way you (and I) could expect them to (and the way they still behave on branch).
As I said, this might be intentional but more probably is the side effect of some other bug fix or performance enhancement (and one could ever argue it's a bug itself, but it doesn't break "generics" behavior as it is specified above).

Didn't know about these generics, thanks. It does kind of make sense, if you go strictly by the standard, that Array.slice.call would expect a meaningless context first arg, and the second arg would be the object to apply to.

al_9x wrote:if you go strictly by the standard, that Array.slice.call would expect a meaningless context first arg, and the second arg would be the object to apply to.

Yes, in Firefox 3.6.3 it behaves like a polymorphic method instead, with the "right" behavior depending on first arg being an array-like object (=generic) or a number/undefined (=instance).

Fixed in latest development build

Confirmed.

The latest dev build of NoScript solved the issue.