Open Bug 11240 Opened 22 years ago Updated 2 years ago

JS errors in event handlers lack file and line number info


(Core :: DOM: Core & HTML, enhancement, P5)





(Reporter: fur, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: [firebug-p3])


(2 files)

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #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?
Assignee: mccabe → rogerl
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.
Assignee: rogerl → troy
Component: Javascript Engine → Layout
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.
Assignee: troy → joki
Tom, this looks like you
Target Milestone: M14
Target Milestone: M14 → M17
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!
Assignee: joki → nisheeth
Nominating nsbeta3 and adding Johnny to the cc list.
Keywords: nsbeta3
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.
Whiteboard: [nsbeta3-]
Target Milestone: M17 → Future
Let's use "number" rather than "#" in the Summary, so obvious bugzilla queries
find this.

Summary: JS_ReportError no longer has line # info → JS_ReportError no longer has line number info
I'll take this one
Assignee: nisheeth → jband
Summary: JS_ReportError no longer has line number info → JS errors in event handlers lack file and line number info
*** Bug 53689 has been marked as a duplicate of this bug. ***
I'm not likely to actually do this anytime soon. Throwing at jst (who might pass
it along).
Assignee: jband → jst
This one must be related to or depending on bug 52116 (or perhaps this other way

*** This bug has been marked as a duplicate of 52116 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
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).
Blocks: 52116
Resolution: DUPLICATE → ---
Depends on: 240421
*** 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. ***
Duplicate of this bug: 418339
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
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.
Assignee: jst → nobody
Component: Layout → DOM
OS: Windows NT → All
Priority: P2 → --
QA Contact: general
Whiteboard: [nsbeta3-]
Target Milestone: Future → ---
Re: call stack,  more realistic code will not inline the event handler:
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";
Severity: normal → enhancement
Whiteboard: [firebug-want]
Whiteboard: [firebug-want] → [firebug-p3]
Blocks: 435025
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...
Depends on: 637572
ping for update!

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.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.