Function logging somewhat vague

[Lawrence San]

When I right-click a function in Firebug's Script tab, and tell it to log a function, it gives me useful feedback in the Console. However, the way it shows the arguments is not as specific as I'd like.

If an incoming argument is a string, it shows me the actual string, which is fine.

However, if an incoming argument is a function name, I'd expect it to show me the function name. Instead, it just reports Object { type="object" }, which is true but not very helpful.

If the incoming argument is an array, I'd like it to show me the name of the variable that was actually passed (which contains the array), or maybe some other information about the array.  Something like "array, length=5" would be good. Instead, it just reports Object { type="object" }, exactly the same as it does for the function, which (again) is true but not very helpful. So I can't even tell whether the argument is a function, or an array, or some other kind of object.

Is there some way to change what Function Logging does, to make it more descriptive? If that's not possible, what would be the easiest way (in the Console) for me to ask to see detailed information about all the arguments passed in to the function?

Thanks much!

--

Lawrence San
Business Writing: Santhology.com
Cartoon Stories for Thoughtful People: Sanstudio.com

[Sebastian Zartner]

There is no way I know of to change the logging.
The easiest way to find out about the passed arguments is to set a breakpoint within the function and while the execution is stopped at it investigate the arguments via the Watch side panel.

As Firebug 3 will be based on the DevTools, you may also want to follow bug 1164882, which targets to implement the logging of function calls for the DevTools.

Sebastian

--
You received this message because you are subscribed to the Google Groups "Firebug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebug+u...@googlegroups.com.
To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/CAMoMLKjoWBe5zGZo%2BBFq0md7uXV%3DABO9jkrUK3gqjPHNCAuG5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[San]

Unfortunately using breakpoints in that way would be far too slow -- it's an "overloaded" variadic function that's called a number of times in rapid succession, each time with a different number of arguments of differing types. What I like about the pure-Console approach (like Function Logging) is that all the calls and arguments flow down in rapid, near-real-time fashion. (BTW, I know there's technically no such thing as an "overloaded function" in JS, but you probably know what I mean.)

I just tried something else, very simple. Within the function body, I put this:

     console.log( arguments );

Interestingly, this gives me both more and less information than Function Logging. On the downside, it doesn't show the name of each parameter; but on the upside, it shows what the value of some of the parameters are. An actual example, for a single iteration of the function call, should make this clear...

Here's what Firebug's Function Logging shows:

waitForElm(elmTrigger="textCol", actionToExecute=Object { type="object"}, arrayOrSrc=Object { type="object"}, bg=undefined)

For the exact same call, here's what using console.log(arguments) shows:

["textCol", setupAnimToggle(animID, animSrc, posterFrame, animSwitch, offCaption, onCaption, initialState), ["mastheadAnim", "EssayMasthead.anim.gif", "EssayMasthead.posterFrame.gif", 4 more...]]

In addition to not showing the parameter name (e.g. Logging's elmTrigger="textCol" is better than just "textCol") this has a few other shortcomings:

1. It jumbles all the parameters together, rather than listing them vertically as #0, #1, #2, etc, which would be much clearer. Ideally, the parameter number AND name AND value should be shown.

2. It doesn't give the parameter types. Some are obviously strings, and (for example) I happen to know that "setupAnimToggle" is a function, and that its arguments came in from an array via 'function.apply', but this listing doesn't indicate any of that.

3. For some reason it doesn't give the complete list, truncating it to "4 more...". (Playing around, I discovered that I can get to the full list with 2 more clicks, which takes me to the DOM tab, and then I can manually switch back to the Console tab -- OK but not ideal. Why does it truncate the list of parameters?)

Perhaps there's some expansion or variation on console.log(arguments) that would deal with some of these shortcomings? Some custom console function that would combine the best features of Function Logging with console.log(arguments)? Either approach (or combining the two, which I'm doing right now but is rather cluttered) seems  incomplete, but still better than slogging through breakpoints. However, perhaps someone has an idea for a custom function (to be nested within the real function inside of a console.log) that would give a more complete readout?

Thanks much!

[Sebastian Zartner]

I've mentioned your request now at bug 1164882 comment 2.

On Friday, November 27, 2015 at 10:41:23 PM UTC+1, San wrote:

Unfortunately using breakpoints in that way would be far too slow -- it's an "overloaded" variadic function that's called a number of times in rapid succession, each time with a different number of arguments of differing types. What I like about the pure-Console approach (like Function Logging) is that all the calls and arguments flow down in rapid, near-real-time fashion. (BTW, I know there's technically no such thing as an "overloaded function" in JS, but you probably know what I mean.)

I just tried something else, very simple. Within the function body, I put this:

     console.log( arguments );

Interestingly, this gives me both more and less information than Function Logging. On the downside, it doesn't show the name of each parameter; but on the upside, it shows what the value of some of the parameters are. An actual example, for a single iteration of the function call, should make this clear...

Here's what Firebug's Function Logging shows:

waitForElm(elmTrigger="textCol", actionToExecute=Object { type="object"}, arrayOrSrc=Object { type="object"}, bg=undefined)

For the exact same call, here's what using console.log(arguments) shows:

["textCol", setupAnimToggle(animID, animSrc, posterFrame, animSwitch, offCaption, onCaption, initialState), ["mastheadAnim", "EssayMasthead.anim.gif", "EssayMasthead.posterFrame.gif", 4 more...]]

In addition to not showing the parameter name (e.g. Logging's elmTrigger="textCol" is better than just "textCol") this has a few other shortcomings:

1. It jumbles all the parameters together, rather than listing them vertically as #0, #1, #2, etc, which would be much clearer.

When you click the array bracket, you'll switch to the DOM panel, where you can see them listed vertically.
 

2. It doesn't give the parameter types. Some are obviously strings, and (for example) I happen to know that "setupAnimToggle" is a function, and that its arguments came in from an array via 'function.apply', but this listing doesn't indicate any of that.

It's relatively easy to see that the setupAnimToggle parameter is a function, because it has parameter brackets and is displayed green in normal font weight like other functions within the DOM panel and described within the wiki.

Whether a function was called normally or with a different this value (i.e. function.apply(), function.call() or function.bind()) is a good idea. You may want to add this info to bug 1164882.

3. For some reason it doesn't give the complete list, truncating it to "4 more...". (Playing around, I discovered that I can get to the full list with 2 more clicks, which takes me to the DOM tab, and then I can manually switch back to the Console tab -- OK but not ideal. Why does it truncate the list of parameters?)

It truncates the list of parameters to reduce memory usage. You can adjust the value via the extensions.firebug.ObjectShortIteratorMax preference.
 

Perhaps there's some expansion or variation on console.log(arguments) that would deal with some of these shortcomings? Some custom console function that would combine the best features of Function Logging with console.log(arguments)? Either approach (or combining the two, which I'm doing right now but is rather cluttered) seems  incomplete, but still better than slogging through breakpoints. However, perhaps someone has an idea for a custom function (to be nested within the real function inside of a console.log) that would give a more complete readout?

As far as I know within the function you just have access to the argument values but not their names. See a related Stack Overflow thread.
Maybe you could do some hacks with Reflect or Proxy, though I didn't try anything in that direction.

Because upcoming versions of Firebug will only be a theme for the Firefox built-in DevTools, you should first check if they already have the feature you want. And if not, you should file an enhancement request for them.

Sebastian