Closed Bug 125612 Opened 23 years ago Closed 8 years ago

RFE: Add function stack trace to Toolkit JS Console reports


(Toolkit Graveyard :: Error Console, enhancement)

Not set


(Not tracked)



(Reporter: WeirdAl, Unassigned)



(Keywords: helpwanted, Whiteboard: parity-opera)

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:     Line Number: 7

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

Error:  All your base are belong to us.

> Source File:     Line Number: 7

And when expanded,

Error:  All your base are belong to us.

\/ Source File:     Line Number: 7
   Function name: foo()  Variables:  a = 1
                                     b = 2

   Called from     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).
Attached to bug 123177 is a sample HTML testcase that generates
errors, and shows what the new Error.stack property looks like:
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?
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;

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

This ventures into XPCOM and C++, specifically


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?
Keywords: helpwanted
Adding nsbeta1 keyword as per caillon's advice.  Need some love from Mountain View.
Keywords: nsbeta1
cc'ing dbradley, jband for their opinion on this -
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
dbradley and I are wondering:  is there a particular reason why the Error()
object itself is not exposed via XPCOM?
OS: Windows 98 → All
Hardware: PC → All
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

Will you need all these instances to report the stack as well or is it ok if the
they have no stack?
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 

Wish I could help you there.
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.
*** Bug 238247 has been marked as a duplicate of this bug. ***
Whiteboard: parity-opera
*** Bug 319766 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
Assignee: hewitt → nobody
QA Contact: jrgmorrison → error-console
Product: SeaMonkey → Toolkit
QA Contact: error-console → error.console
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
This has been fixed via bug 814497 and bug 1184172.
We now can see the stacks in the webconsole!
Closed: 9 years ago
Resolution: --- → DUPLICATE
(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.
Depends on: 814497
Resolution: DUPLICATE → ---
See Also: → 1184172
Summary: RFE: Add function stack trace to JS Console reports → RFE: Add function stack trace to Toolkit JS Console reports
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.
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.
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.
Closed: 9 years ago8 years ago
Resolution: --- → WONTFIX
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.)
Component: Error Console → Developer Tools: Console
Product: Toolkit → Firefox
Resolution: WONTFIX → ---
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.
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Component: Developer Tools: Console → Error Console
Product: Firefox → Toolkit
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.