• What steps will reproduce the problem?

Open attached .html file

• What is the expected output? What do you see instead?

Expected: A full traceback to be available (through the "plus button"). What I see: A single-line describing the exception without a traceback.

• What version of the product are you using? On what operating system?

Firefox 3.0.3 on Linux. Tested with Firebug 1.2.1 and Firebug 1.3b2 (end-user version).

• Please provide any additional information below.

I'm not married to the "throw new Error('xxx')" syntax. I just want a way to get a nice traceback on a manually thrown exception, without resorting to purposely using an undefined variable to trigger one (which is the only way I've found so far).

https://bugzilla.mozilla.org/show_bug.cgi?id=465672

Problem is caused by firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=465672

just marking with new standard tag

I don't think this is practical. The problem is that a lot of code issues "throw" and a lot of code has a deep stack trace. So to implement this feature we have to store a lot of data for a lot of cases where it will not be used, just in case you might need it.

In particular I don't think we know if an exception will be caught. So we don't know that the throw will result in an uncaught exception until the entire stack has been unwound.

In Firebug 1.5b5 you get an error message with a source line and grey dot. Click on the dot and re-run. You break on the throw.

You can also try console.error("Help me, Help me Mr. Wizard"); to get a stack trace.

I haven't tested it yet, but it sounds awesome, thanks!

Issue 3043 has been merged into this issue.

Just tried the test case in FF 9.0a1 + FB 1.9.0a2 and saw, that there is still no stack trace shown. Wasn't there a change lately, that should fix that? At least the source name abbreviation in the console is great: test_f...ck.html ;-)

johnjbarton,

to implement this feature we have to store a lot of data for a lot of cases where it will not be used, just in case you might need it.

The problem is that developers can't see a stack trace when it would be useful to see one, right? Well 99 times out of 100 that's going to be the stack trace of the very last exception thrown. And even in those 1 out of 100 times when it isn't, 99 out of 100 would be in the last few (5? 10?) errors to be thrown.

So if Firebug just stored the last ten deep stacktraces (that it otherwise currently wouldn't store), you'd be solving the vast majority of the problem, and you wouldn't have "to store a lot of data for a lot of cases" (or at least, not for very long), to do it.

I agree with comment 13; more over, even the newest 10 stack frames would be a great help.

Wasn't there a change lately, that should fix that? What change?

From reading source code, this seems related to the logic for "Track Throw/Catch", but that's old and broken. I tried to fix things - jjb, would you mind taking a look at the patch? Making it work with less memory is doable, but hard.

I thought Honza was going to remove the Track Throw/Catch code?

Unfortunately I don't know anything special about this code now, but Honza should.

re: Memory, the fix needs to be on the jsd side, to avoid rendering frames into the JS side at all. The V8 team did that for Chrome.

Fixed with issue 5544, I believe.