(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #333856 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=333856 Imported into Bugzilla on 08/04/99 01:47) I'm surprised we didn't notice this regression much earlier: Errors in host object methods don't list filename/line number information, i.e. errors reported using JS_ReportError(). This is because fp->script is NULL.

Added Roger to cc: list, because this this sounds like another aspect of an earlier issue... weren't there other repercussions of fp->script being NULL?

Recussitating fossil Bugsplat bugs. I'm not sure if this is still valid, but it'll tie into any error/exception work. Reassigning to Roger...

Removed extra rogerl cc (and added mccabe)

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

roger, are errors as excptions holding this one up? this would be really helpful to have fixed.

This bug occurs because 'nsEventListenerManager::AddScriptEventListener' in "layouts/events/src/nsEventListener.cpp" calls 'JS_CompileUCFunctionForPrincipals' with the filename and line number set to null and 0 respectively. If that could be fixed to pass the script name and line number I think things would be just wonderful; in a local sense.

Tom, this looks like you

Moving M17. Not a user feature. Want for FCS for developers though.

Tempted to FUTURE this, painful though that is. Only thing that's stopping me is the knowledge that lots of content developers will be upgrading web content & apps to support Moz/N6, and we want to make their lives as easy as possible during this upgrade. joki, your call. If this is easy & you've got time, we'd love to have it fixed, but if you can't, we can FUTURE it.

Nisheeth volunteered to take this. The fool!

Nominating nsbeta3 and adding Johnny to the cc list.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration, but do not clear the nsbeta3- nomination.

Let's use "number" rather than "#" in the Summary, so obvious bugzilla queries find this. /be

I'll take this one

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

http://lxr.mozilla.org/classic/source/lib/libmocha/lm_init.c#298, a blast from the past. /be

I'm not likely to actually do this anytime soon. Throwing at jst (who might pass it along).

This one must be related to or depending on bug 52116 (or perhaps this other way around): http://bugzilla.mozilla.org/show_bug.cgi?id=52116

*** This bug has been marked as a duplicate of 52116 ***

v

I'm going to reopen this. This got marked as duplicate of a hell-hole of a vague bug that's not reasonably fixable because it's not clear what exactly the problem is. _THIS_ bug is about a very specific problem, on the other hand. Marking the other bug dependent on this one, since I bet there are other cases where JS "errors" (whatever that means in the other bug) won't include relevant info (eg CAPS exceptions).

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

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

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

Bug 418339 suggests: ----------------------------------------------------------------------------- The kinds of information that would help developers and should be easily available include: -- the body of the event handler: function onclick(event) {, throw 1;, } -- the call stack at the point of error -- the event that was being processed when the exception occurred. -- the element whose attribute contained the event handler. The call stack is the most important as it would allow the other stuff to be accessed. ----------------------------------------------------------------------------- There is no call stack here, since the event handler is the only thing on the stack. But it would be nice to have some of these other things. John suggested xpath to identify the element. We'd probably need new JS engine API to allow it to query for this stuff or something; we don't want to cart it around all the time.

Re: call stack, more realistic code will not inline the event handler: <script> function dubiousFunction(event) { throw "i'm dubious"; // Wow, if I had a call stack I'd nail this baby. } var d = document.createElement("div"); d.onclick = dubiousFunction; d.innerHTML = "ClickMe"; document.body.appendChild(d); </script>

I'm guessing this is still a bug. The first testcase does produce errors with callstacks and (false, in the case of button #2) line numbers. Found during triage. Wondering if there's anything we can do here...

ping for update!

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.