Drosera's function list will list as "(anonymous function)" any function defined using the syntax: SomeObject.someMethod = function(a, b) { ... } or SomeObject.prototype.someMethod = function(a, b) { ... } This makes the function list not very useful if this particular syntax is frequently used (as it is in the projects I work on). Please enable Drosera to determine the function name for methods defined by such syntax.
It is obvious why this is desirable, but what is less obvious is the difficulty in providing this. At the time the function object is created, it is anonymous. Assigning it to a variable or to property on another object does not change this fact. Consider the following example: SomeObject.someMethod = function(a, b) { }; SomeOtherObject.someOtherMethod = SomeObject.someMethod; SomeOtherObject.someOtherMethod(1, 2); What name should Drosera give to the frame created by the function call in the third line? Coming up with a solution to this single case appears relatively easy, but is tricky to generalise in a fashion that won't produce more confusing results in some cases.
I agree, it is tricky. For what it's worth, here's what I've gathered from my observation of other debugging environments, based on this example: function SomeObject() { } function SomeObject2() { } SomeObject.methodA = function() { var a = "A"; }; var tempMethod = function() { var b = "B"; }; SomeObject.prototype.methodB = tempMethod; SomeObject.prototype.methodC = SomeObject.methodA; SomeObject2.prototype.methodD = SomeObject.prototype.methodB; function test() { var a = new SomeObject(); var b = new SomeObject2(); SomeObject.methodA(); a.methodC(); a.methodB(); b.methodD(); } Venkman labels functions with the name of what the function literal is originally assigned to. For this example, Venkman lists two methods labeled "methodA" and "tempMethod", both in the function list and in the call stack. Firebug just goes with "anonymous", like Drosera currently does. I don't have a Windows machine handy to test Visual Studio's debugger. Not knowing anything about how Drosera does its thing, I don't know how this would work, but it seems to me that the ideal solution would go beyond Venkman's. It would be great if it would show both the constructor-name-of-'this' and the callee name, as well as referencing the name and context of the original name. Maybe something along the lines of: SomeObject.methodA SomeObject.prototype.methodC -> SomeObject.methodA SomeObject.prototype.methodB -> window.tempMethod SomeObject2.prototype.methodD -> window.tempMethod That's getting a bit verbose, but I don't think it would cause confusion. I must say that I have done heavy-duty JavaScript/AJAX development using Venkman for several years, and I have never once been confused by their function labels. So that solution, while not ideal, appears to me to be adequate.
Related to bug 9596.
Related to bug 11525.
I've noted that the MochiKit JavaScript library allows assigning a "NAME" property to anonymous functions. I guess other libraries could have similar mechanisms (as the ordinary function "name" property is read-only). Perhaps a work-around for this issue would be for Drosera to print the "NAME" value if "name" is undefined? It is pretty easy to name all functions in a namespace with this method by iterating over all properties, objects and prototypes.
Coming up with a good system here would make debugging the Inspector a lot easier.
Still applies to the Web Inspector debugger, moving to that component.
Is this solved by the Inspector using function's "displayName" property like comment 5 suggests and as detailed in this April 2009 article: http://www.alertdebugging.com/2009/04/29/building-a-better-javascript-profiler-with-webkit/ For the example in this bug report: SomeObj.someMethod = function(a,b) { ... }; SomeObj.someMethod.displayName = 'SomeObj.someMethod'; Will properly display SomeObj.someMethod in the profiler.
We also auto detect the name now. Try the latest nightly.