Closed Bug 1110276 Opened 10 years ago Closed 5 years ago

Log on Events (aka monitorEvents/Event Tracing)


(DevTools :: Debugger, enhancement, P3)



(relnote-firefox -, firefox71 fixed)

Firefox 71
Tracking Status
relnote-firefox --- -
firefox71 --- fixed


(Reporter: canuckistani, Assigned: jlast)


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


(Keywords: dev-doc-complete, Whiteboard: [debugger-reserve])


(2 files)

Interesting idea in from uservoice:

"...something like an event console that will output timestamped log lines every time those events fire, with those log lines being clickable to display the call stack or to jump to the debugger at that function call."

I think we already do the most basic level of this by allowing developers to break on specific events. What I think is interesting is more the idea of *tracing* specific events as they happen and being able to show the async stack associated with them.
A relevant feature in Chrome is monitorEvents:  It does give insight into when they are being fired,  but I don't think it ties back to the bound callbacks, which would be very useful.
Pretty much the only thing the timeline does is trace events... Should we change this to copying the feature from comment 1?
(In reply to Nick Fitzgerald [:fitzgen] from comment #2)
> Pretty much the only thing the timeline does is trace events... Should we
> change this to copying the feature from comment 1?

Does the timeline give you insight into which callbacks are fired due to the events?  This would be more useful than simply seeing that the DOM events fired.
I don't think we do yet, but perhaps :tromey has ideas on how this type of metadata might be added.
Flags: needinfo?(ttromey)
From what I can tell, the only way to propagate this metadata is to update
users of AutoEntryScript to notify the docshell of the object being called.
There's on the order of 50 such spots (for some of these there is nothing to
be done, but one must at least examine them all).

I think last time we discussed this the "AutoEntryScript bug" (bug 971573 and
bug 961325) came up, but my understanding is that these are about the other direction,
namely having the platform provide SpiderMonkey with some reason for the call.
Flags: needinfo?(ttromey)
Re reading the initial request, I wonder if this is more an extension of the event bubbles we have in the inspector already, adding the ability to trace when these calls actually happen.  In this case we already have information about the bound function - maybe there is a way to get a stacktrace when that function is called.

Jeff, do you think this is something that our current events bubble UI could handle if we added logging/breaking features?  Or is this something you see fitting into the debugger or timeline?  Or (please no) an entirely new panel?
My read of the request - it's a bit vague admittedly - is that he's talking about the debugger. He makes some other useful suggestions about filtering events in that panel as well.
Blocks: dbg-dom
Product: Firefox → DevTools
Type: defect → enhancement
OS: macOS → Unspecified
Hardware: x86 → Unspecified
Summary: Event tracing → Monitor/log/trace Events
Priority: -- → P3
No longer blocks: dbg-dom, dbg-event-bps
Depends on: dbg-event-bps
No longer depends on: async-stacks
Summary: Monitor/log/trace Events → Log on Events (aka monitorEvents/Event Tracing)
Version: 36 Branch → unspecified
Assignee: nobody → jlaster
Blocks: dbg-71
Whiteboard: [debugger-reserve]
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
Regressions: 1581995
Regressions: 1581999
Depends on: 1594374
Depends on: 1594382

Release Note Request (optional, but appreciated)
[Why is this notable]: Understanding event handling is one of the key pillars of debugging web apps.
[Affects Firefox for Android]: No
[Suggested wording]: Logging for specific event types can be enabled in the Event Listener Breakpoints panel in the Debugger. You can then observe which event handlers are being executed without the overhead of pausing.
[Links (documentation, blog post, etc)]: (TBD)

relnote-firefox: --- → ?

Not selected by the comms team for our general release notes, it should probably go to our developer release notes for 71 on MDN.

I've completed documentation for this; see for the full details.

You need to log in before you can comment on or make changes to this bug.