RFE: Add function stack trace to Toolkit JS Console reports

RESOLVED FIXED

Status

enhancement
RESOLVED FIXED
18 years ago
3 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

({helpwanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: parity-opera)

Reporter

Description

18 years ago
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

18 years ago
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
Reporter

Comment 2

17 years ago
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?
Reporter

Comment 3

17 years ago
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?
Keywords: helpwanted
Reporter

Comment 4

17 years ago
Adding nsbeta1 keyword as per caillon's advice.  Need some love from Mountain View.
Keywords: nsbeta1

Comment 5

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

Comment 6

17 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
Reporter

Comment 7

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

Updated

17 years ago
OS: Windows 98 → All
Hardware: PC → All

Comment 8

17 years ago
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?
Reporter

Comment 9

17 years ago
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

17 years ago
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

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

Updated

15 years ago
Whiteboard: parity-opera

Comment 12

14 years ago
*** Bug 319766 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
Assignee: hewitt → nobody
QA Contact: jrgmorrison → error-console
Component: Error Console → Error Console
Product: SeaMonkey → Toolkit
QA Contact: error-console → error.console

Comment 13

8 years ago
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!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 814497

Comment 15

4 years ago
(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.
Status: RESOLVED → REOPENED
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.

Comment 17

4 years ago
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.
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago3 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.)
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 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.