Bug 30614 – Web Inspector: Render timeline information in the frontend

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Pavel Feldman]

I wanted to do a real quick proof of concept rendering for the timeline events and ended up using resources panel for that. So I created artificial resources for the timeline events and hacked the categories a bit. (Am attaching screenshots with what it looks like shortly).

Why I like it:
- it is very simple and nice
- it has aggregated data info
- it has filters
- it actually survives the page transition
- it shows duration in the tooltip :)

What it misses:
- folding
- zooming

Although we agreed to make timeline a part of the profiles panel, I think we should reuse resources panel rendering code for it. What do you think?

[Pavel Feldman]

Created attachment 41542 [details]
[IMAGE] Search result page timeline

[Timothy Hatcher]

Very nice! Sure, I think we could start from this.

When you say folding, do you mean showing all the layouts on one row with multiple line segments spaced in time? I think that would be interesting. We would likely need to change the look, since the resource bubbles have a min width, so they could overlap in that case.

[Timothy Hatcher]

We have also considered adding zooming to the Resources panel too. So you only see by default the resources that happened during the initial load. And future loads (XHRs, etc) would be scrolled horizontally off the right (and likely auto scroll right to show them). With some adjustable zoom slider.

[Pavel Feldman]

Created attachment 41565 [details]
[IMAGE] Resources mixed with other types of events

[Pavel Feldman]

Created attachment 41566 [details]
[IMAGE] Evaluate causing too many css adjustments

[Pavel Feldman]

I thought about it for some time and here is what I'd suggest:

Add a TimelinePanel that looks like the one on the screenshots. Leave resources panel as is.

- This timeline panel will not have sticky enabled mode - one will need to enable it each time he opens inspector. Enable splash screen will have a list of events with checkboxes against them though. These are instrumentation settings, are stored in inspector settings.

- Render timeline bars differently: do not use round bars, adjust style a bit so that user could differentiate this panel from resources one.

- On this new panel, paint all resources using same color (blue). These are load events. Paint other types of events using other, different colors.

- Remove time/size elements. Stack timeline graph and aggredated legend at the top.

- Event instrumentation should be configurable, a button in status bar leads to the splash screen with settings. (Use 3D CSS to flip to settings as on iPhone :)?).

- Every log entry is collapsible, one can collapse all.

- There is a zoom window on the timeline

- Every log entry is selectable, upon selection it provides textual information about its start / end / information specific to the event. Parent items provide aggregated graphs with distribution of time between their children types (as the top one in resources).

What do you think?

[Timothy Hatcher]

(In reply to comment #6)
> I thought about it for some time and here is what I'd suggest:
> 
> Add a TimelinePanel that looks like the one on the screenshots. Leave resources
> panel as is.

This makes sense to me.

> - This timeline panel will not have sticky enabled mode - one will need to
> enable it each time he opens inspector. Enable splash screen will have a list
> of events with checkboxes against them though. These are instrumentation
> settings, are stored in inspector settings.

I guess it is sticky until you close the Inspector right? Why not make it global sticky? Other panels are just as bad to keep always enabled. Why not let this one?

> - Render timeline bars differently: do not use round bars, adjust style a bit
> so that user could differentiate this panel from resources one.

I agree. I will mock this up in a little bit.

> - On this new panel, paint all resources using same color (blue). These are
> load events. Paint other types of events using other, different colors.

So the resources you see corispond to load events? Is the bar as long as it would be on the Resources panel, or just as long as it takes to fire the load event?

> - Remove time/size elements. Stack timeline graph and aggredated legend at the
> top.

Yep.

> - Event instrumentation should be configurable, a button in status bar leads to
> the splash screen with settings. (Use 3D CSS to flip to settings as on iPhone
> :)?).

Would changing the config reset the timeline?

> - Every log entry is collapsible, one can collapse all.

Yep. I also have another idea that I want to explore and will include in my mockup.

A seperate mode that aggregates on event type, instead of the waterfall look. So rows like "Load", "Parse HTML", "Evaluate", etc. All the events of each type would show up as broken lines. I think this will give a superior overview to everything. Clicking on (or maybe expanding) a row would show you a waterfall for that type. But that might not be super useful, since you loose context with other events… hmm. I'll think about this expanded state some more.

> - There is a zoom window on the timeline

Yep. We might want this on Resources too.

> - Every log entry is selectable, upon selection it provides textual information
> about its start / end / information specific to the event. Parent items provide
> aggregated graphs with distribution of time between their children types (as
> the top one in resources).

Sounds cool to me.

[Pavel Feldman]

> I guess it is sticky until you close the Inspector right? Why not make it
> global sticky? Other panels are just as bad to keep always enabled. Why not let
> this one?

Three reasons here:

1) it is resource consuming and it actually slows things down a bit
2) currently timeline only works when frontend is there, events are pushed straight into it, not collected in inspector controller
3) this thing is supposed to survive refresh, so if we are collecting events we might go out of heap without knowing it (with inspector closed)

> So the resources you see corispond to load events? Is the bar as long as it
> would be on the Resources panel, or just as long as it takes to fire the load
> event?

I was more saying that we should not differentiate between types of resources. I should not have used 'it is load event' term, i still think resource load should be separate from the load event that happens once resource is there.

> 
> Would changing the config reset the timeline?

I don't think it should. It would just start adding more colors to the subsequent timeline.

I'll wait for you to come up with the mocks and then will be able to hack it while flying over the ocean. I'd like to agree on the sticky bit though since it affects the way timeline events are actually collected (whether we need to cache them in InspectorController or not).

[Timothy Hatcher]

(In reply to comment #8)
> > I guess it is sticky until you close the Inspector right? Why not make it
> > global sticky? Other panels are just as bad to keep always enabled. Why not let
> > this one?
> 
> Three reasons here:
> 
> 1) it is resource consuming and it actually slows things down a bit
> 2) currently timeline only works when frontend is there, events are pushed
> straight into it, not collected in inspector controller
> 3) this thing is supposed to survive refresh, so if we are collecting events we
> might go out of heap without knowing it (with inspector closed)

OK, I buy that.

> > So the resources you see corispond to load events? Is the bar as long as it
> > would be on the Resources panel, or just as long as it takes to fire the load
> > event?
> 
> I was more saying that we should not differentiate between types of resources.
> I should not have used 'it is load event' term, i still think resource load
> should be separate from the load event that happens once resource is there.

OK.

> > Would changing the config reset the timeline?
> 
> I don't think it should. It would just start adding more colors to the
> subsequent timeline.

Makes sense. Was just checking.

> I'll wait for you to come up with the mocks and then will be able to hack it
> while flying over the ocean. I'd like to agree on the sticky bit though since
> it affects the way timeline events are actually collected (whether we need to
> cache them in InspectorController or not).

I agree with oyu on the sticky bit.

[Timothy Hatcher]

(In reply to comment #6)
> - This timeline panel will not have sticky enabled mode - one will need to
> enable it each time he opens inspector. Enable splash screen will have a list
> of events with checkboxes against them though. These are instrumentation
> settings, are stored in inspector settings.

Why do you need to fine grain control what events to record? This is like stabbing at the problem before you know what the problem is! Wont after-the-fact filtering/searching be better?

[Pavel Feldman]

> Why do you need to fine grain control what events to record? This is like
> stabbing at the problem before you know what the problem is! Wont
> after-the-fact filtering/searching be better?

APU was showing me a locally modified build where thy were instrumenting bindings. That was a lot more chatty and I thought that filtering that level might make sense. They don't put it in yet, so it can wait.

[Kelly Norton]

(In reply to comment #10)
> (In reply to comment #6)
> > - This timeline panel will not have sticky enabled mode - one will need to
> > enable it each time he opens inspector. Enable splash screen will have a list
> > of events with checkboxes against them though. These are instrumentation
> > settings, are stored in inspector settings.
> 
> Why do you need to fine grain control what events to record? This is like
> stabbing at the problem before you know what the problem is! Wont
> after-the-fact filtering/searching be better?

FWIW. In our work with APU, we're finding this approach better then pre-configuring. We've seen a lot of cases where developers start with a "slow user action." They turn on APU, redo the user action, then filter and zoom (this one has been big for APU because people use the graph to drill straight down on the problem events). Having whittled the data down to a couple of events, they then begin looking at the details.

In fact, I have to say that one of the reasons we were so motivated to build heterogenous trace trees is that developer intuitions are often so far off that it's hard to pick a direction without at least a cursory look at what is going on under the hood.

[Brian Weinstein]

Does this bug need to be open anymore?

[Pavel Feldman]

All patches are landed in other bugs. Closing as fixed.