Enable logging event breakpoints

[jasonLaster]

We currently have "Event Listener Breakpoints", "DOM Mutation Breakpoints", and "XHR Breakpoints". We'll soon have "Watchpoints". All of these features enable pausing at some point in time. It would be great if we could also enable logging at these points in time.

The benefit is that sometimes you do not want to pause at ONE point, but instead log all of the points and view the sequence of events...

It would also be helpful to be able to conditionally log/pause at these events to prevent some of the noise.

I think there are three levels of logging we can enable:

1. toggle logging for all types of event breakpoints
2. toggle logging for a type of event breakpoints e.g. xhr breakpoints
3. toggle logging for a specific breakpoint

Option 1

it would likely be somewhere global like next to the disable breakpoints button.

Option 2

Option 3

Here is a figma where we can sketch

---

One other thing to discuss is how to show the logged events in the console. The most similar example is log points where we show a purple breakpoint.

Here is a loom video of me using the feature.

[digitarald]

Related discussion from an older bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1110276

[digitarald]

I added the last version in Option 3 as my fav. Easy to get to and solve the v0 problem how to allow to quickly discover and use logged event points. Still needs more work, as the close button appears around the same place, but I am sure that we can experiment a bit to align things.

[jasonLaster]

I agree that v3 is ideal and it could help with breakpoints too. It would be nice to be able to add a condition as well.

[fvsch]

I like Option 3 because it's the most powerful and a good first step for starting to treat breakpoints as "points in time" when users can choose to (conditionally) log and/or break. As a power user this feels like the least hassle for getting the most control.

But I'm unclear on what the main use cases are and I'm wondering if Option 2 wouldn't serve them better. If the main use case is about logging a lot of events as they happen to get a wide view of "what is happening when I do X", a category-wide toggle might be better than tweaking every kind of Event breakpoint family or single breakpoint to turn them into log points (that would be a lot of manual work)?

[fvsch]

treat breakpoints as "points in time" when users can choose to (conditionally) log and/or break

Illustration with two variants on the "Option 3 > on select" UI:

[jasonLaster]

If the main use case is about logging a lot of events

That's a good point. I'm not sure if users will want to log some events and pause on others.

[digitarald]

That's a good point. I'm not sure if users will want to log some events and pause on others.

Right. Question would be if we map monitorEvent to UI, it does add levels of complication. Toggling a whole panel from pausing to logging does not map to how Logpoints work atm.

The settings dialog is similar to what I had put together as "overkill"-option for logpoints.

[digitarald]

Now in Nightly, design by Jason:

[violasong]

This looks great - nice work Jason!

Does this solve the problem for now, or are we still considering finer-grained logging options?

[digitarald]

Works for now! Next phase is gathering some feedback.

[digitarald]

Only general follow up would be to maybe come up with something better than checkbox/label design for those panel options. We used the same for Map Scopes and it does feel sub-optimal (while exposing it nicely), so worth a discussion.

[digitarald]

Landed and solved for now until we have better ideas.