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
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?
Adding nsbeta1 keyword as per caillon's advice. Need some love from Mountain View.
cc'ing dbradley, jband for their opinion on this -
dbradley and I are wondering: is there a particular reason why the Error() object itself is not exposed via XPCOM?
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?
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.
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. ***
*** Bug 319766 has been marked as a duplicate of this bug. ***
Assignee: hewitt → nobody
QA Contact: jrgmorrison → error-console
Component: Error Console → 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!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 814497
(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.
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.
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 ago → 3 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 ago → 3 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.