125612 - RFE: Add function stack trace to Toolkit JS Console reports

Status: RESOLVED FIXED

(Toolkit Graveyard :: Error Console, enhancement)

Description

[Alex Vincent [:WeirdAl]]

I recently filed bug 123177, which Brendan Eich was so kind to agree to and 
fix.  We now have a stack property of Error() objects and exceptions, which we 
can use in debugging efforts.

This bug is to suggest adding the stack property to JavaScript console messages, 
both in the console itself and in the toString() method of each message (for 
instance, if I want to copy the message).

Currently, I believe errors are reported in the following format:

Error:  All your base are belong to us.

Source File: http://www.jslab.org/temps/blah.js     Line Number: 7
-----------------------

I would suggest the source file & line number change somewhat:

Error:  All your base are belong to us.

> Source File: http://www.jslab.org/temps/blah.js     Line Number: 7
-----------------------

And when expanded,

Error:  All your base are belong to us.

\/ Source File: http://www.jslab.org/temps/blah.js     Line Number: 7
   Function name: foo()  Variables:  a = 1
                                     b = 2

   Called from http://www.jslab.org/temps/blah.htm     Line Number: 68
   Function name: bar()  Variables:  c = 3
-----------------------

Opinions?  I'd do it myself, but my online time is currently very limited (I 
cannot even download a Mozilla build onto my current machine).

Comment 1

[Phil Schwartau]

Attached to bug 123177 is a sample HTML testcase that generates
errors, and shows what the new Error.stack property looks like:

 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=69615

Comment 2

[Alex Vincent [:WeirdAl]]

My time limitations appear to have ended for now.  I'm back online.

That being the case, I'd like to ask hewitt if I could take over ownership of
this bug.  I'd also like to see if I can get it prepped, fast, for 1.0.  I think
I can do it.  (We're talking eight days before the freeze, including patch, r=,
sr=, and a=.)

It's a shot in the dark... anybody wearing night-vision glasses?

Comment 3

[Alex Vincent [:WeirdAl]]

I'm gonna need some help here.  This goes beyond a Patch Maker build.

I looked at the appendError() method of consoleBindings.xml.  It receives an
aObject argument.  But that aObject argument comes from:

var scriptError = aObject.QueryInterface(Components.interfaces.nsIScriptError);

This comes from the appendItem() method.

scriptError has the following properties:

message; QueryInterface; flags; lineNumber; sourceName; sourceLine;
columnNumber; category; init; toString; errorFlag; warningFlag; exceptionFlag;
strictFlag

It doesn't have a stack property, which is what I need.

This ventures into XPCOM and C++, specifically 

http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/nsScriptError.cpp

and 

http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/idl/nsIScriptError.idl

helpwanted:  Can someone create a patch which correctly and safely adds the
Error.prototype.stack property to the nsIScriptError interface, so I can get it
from JavaScript?

Comment 4

[Alex Vincent [:WeirdAl]]

Adding nsbeta1 keyword as per caillon's advice.  Need some love from Mountain View.

Comment 5

[Phil Schwartau]

cc'ing dbradley, jband for their opinion on this -

Comment 6

[Peter Trudelle]

Nav triage team: nsbeta1-

Comment 7

[Alex Vincent [:WeirdAl]]

dbradley and I are wondering:  is there a particular reason why the Error()
object itself is not exposed via XPCOM?

Comment 8

[David Bradley]

This will require more than just "exposing" the stack from nsIScriptError. The
code that builds this object will need to be patched and that's more than just
xpconnect, for instance
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsJSEnvironment.cpp#229

Will you need all these instances to report the stack as well or is it ok if the
they have no stack?

Comment 9

[Alex Vincent [:WeirdAl]]

Um, I don't know.  My main goal is to give us a stack which the Console can use.  As I 
understand it, Venkman has its own stack tracing feature, so it probably won't be needed 
there.

Wish I could help you there.

Comment 10

[Kevin A. Burton]

The JS debugger in Mozilla supports catching runtime exceptions.  Is should be
possible to write a plugin to add support for this in past versions of Mozilla
as well.  This would be a quick workaround.  

There are some downsides here:

- It really *should* be a platform feature.  Why we have gotten this far without
stacktraces I will never know!

- The messages logged in the console will be logged twice.  Once for the
nsIScriptError and then for the stacktrace caught by the plugin.

- The debugger will have to be enabled which I assume will slow down Mozilla.

Comment 11

[Rene Pronk]

*** Bug 238247 has been marked as a duplicate of this bug. ***

Comment 12

[Jesse Ruderman]

*** Bug 319766 has been marked as a duplicate of this bug. ***

Comment 13

[al_9x]

In Fx 5.0 a number of extensions are causing the following to be logged:

Error: gBrowser.addProgressListener was called with a second argument, which is not supported. See bug 608628.
Source file: chrome://browser/content/tabbrowser.xml
Line: 1840

but without the stack trace you don't know which extension

Comment 14

[Alexandre Poirot [:ochameau]]

This has been fixed via bug 814497 and bug 1184172.
We now can see the stacks in the webconsole!

Comment 15

[Philip Chee]

(In reply to Alexandre Poirot [:ochameau] from comment #14)
> This has been fixed via bug 814497 and bug 1184172.
> We now can see the stacks in the webconsole!
Thank you. Not a DUP.

Comment 16

[Alexandre Poirot [:ochameau]]

I don't see what is still missing, could you refine?
These patches I mentioned don't cover some chrome codepath, but stacks are displayed for webpages.

Comment 17

[Philip Chee]

This bug is in the Toolkit Error Console component, not the Devtools Web Console.
Still in use by SeaMonkey, Thunderbird, Instantbird and other toolkit based applications.

Comment 18

[Brian Grinstead [:bgrins]]

The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed.  If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.

Comment 19

[Zack Weinberg (:zwol)]

I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.

If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid.  Do not push that work onto the bug reporters.

(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify.  But that is the ONLY situation where it is okay.)

(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works.  Apologies for the extra bugspam.)

Comment 20

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Since the DevTools console show stack traces and the error console is gone, I believe there is nothing to do in this bug.  I guess it's FIXED by using the DevTools console.