Jeff Griffiths (:canuckistani) (:⚡︎) Reporter
	Description • 10 years ago

Interesting idea in from uservoice:

https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/6831191-event-panel

"...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.

	Brian Grinstead [:bgrins]
	Comment 1 • 10 years ago

A relevant feature in Chrome is monitorEvents: https://developer.chrome.com/devtools/docs/commandline-api#monitoreventsobject-events.  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.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 2 • 10 years ago

Pretty much the only thing the timeline does is trace events... Should we change this to copying the feature from comment 1?

	Brian Grinstead [:bgrins]
	Comment 3 • 10 years ago

(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.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 4 • 10 years ago

I don't think we do yet, but perhaps :tromey has ideas on how this type of metadata might be added.

	Tom Tromey :tromey
	Comment 5 • 10 years ago

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.

	Brian Grinstead [:bgrins]
	Comment 6 • 10 years ago

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?

	Jeff Griffiths (:canuckistani) (:⚡︎) Reporter
	Comment 7 • 10 years ago

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.

	Pulsebot
	Comment 10 • 5 years ago

Pushed by jlaster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/beefeb1ecf47
Log on Events. r=bhackett

	Pulsebot
	Comment 13 • 5 years ago

Pushed by jlaster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/05044e24d55d
Log on Events (UI). r=davidwalsh