1110276 - Log on Events (aka monitorEvents/Event Tracing)

Status: RESOLVED FIXED

(DevTools :: Debugger, enhancement, P3)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

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.

Comment 1

[Brian Grinstead [:bgrins]]

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.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 3

[Brian Grinstead [:bgrins]]

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

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 5

[Tom Tromey :tromey]

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.

Comment 6

[Brian Grinstead [:bgrins]]

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?

Comment 7

[Jeff Griffiths (:canuckistani) (:⚡︎)]

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.

Comment 8

[:Harald Kirschner :digitarald]

Related: https://developers.google.com/web/tools/chrome-devtools/console/events

Comment 9

[Jason Laster [:jlast]]

Attachment: Bug 1110276 - Log on Events. r=bhackett

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/beefeb1ecf47
Log on Events. r=bhackett

Comment 11

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/beefeb1ecf47

Comment 12

[Jason Laster [:jlast]]

Attachment: Bug 1110276 - Log on Events (UI). r=davidwalsh

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/05044e24d55d
Log on Events (UI). r=davidwalsh

Comment 14

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/05044e24d55d

Comment 15

[:Harald Kirschner :digitarald]

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)]: https://developer.mozilla.org/en-US/docs/Tools/Debugger/Set_event_listener_breakpoints (TBD)

Comment 16

[Pascal Chevrel (relman team) -> :pascalc]

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

Comment 17

[Chris Mills [:cmills]]

I've completed documentation for this; see https://github.com/mdn/sprints/issues/2276#issuecomment-559236958 for the full details.