1471249 - Add Start, End And Duration To Timings Tab

Status: RESOLVED DUPLICATE of bug 1580431

(DevTools :: Netmonitor, enhancement, P3)

Description

[Dave Hawkins]

The timings tab for a call shows the durations of various parts of the call. It should also show the start/end times and the duration.

Comment 1

[Florens Verschelde :fvsch]

Attachment: network-request-timing-details.png

Now that we're hiding the waterfall column when a request is selected, we're missing visual indicators for when the request started and how long it took.

It would be great to have this information in the Timings tab.

Comment 2

[:Harald Kirschner :digitarald]

Attachment: image.png

Chrome also just shows the 2 times in the top of the timing. I would just add them to the 2 column layout below, just without the bar graphs.

Comment 3

[:Harald Kirschner :digitarald]

Honza, do you have some guidance please to make this a good-first-bug?

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report!

Some instructions for anyone interested in fixing this bug:

1. The Timings panel is represented by TimingsPanel component and is rendered here
   https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/TimingsPanel.js#96

2. All timings data are accessible form props using this.props.request.eventTimings
   https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/TimingsPanel.js#103

3. There is also RequestListColumnTime component (used for Timings columns: Start Time, End Time, etc.) showing how to calculate relative times (relative to the first top level document request)
   https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/RequestListColumnTime.js#54

4. I believe that queued time corresponds to Blocked time start and Started to Blocked time end.

Honza

Comment 5

[Hayden Huang]

Hello everyone! I am a University of Toronto compsci student interested in picking this bug up as my first Mozilla bug. Can I take this? And is there anything I should be aware before I start?

Comment 6

[:Harald Kirschner :digitarald]

Hi Hayden Huang. I assigned the bug, please let us know if Honza's instructions above are enough to get you started.

Comment 7

[Hayden Huang]

(In reply to :Harald Kirschner :digitarald from comment #6)

Hi Hayden Huang. I assigned the bug, please let us know if Honza's instructions above are enough to get you started.

Thanks, for now I am still looking thought the two js files Jan Honza shown and try to located the file used to display these time information, and can you be more specific about how the queued and start time be calculated? I am still a bit of confusion.

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

We need to calculate two values:

• Started - time relative to the first request start time (so, the first request has start time 0)
• Queued - time spent in the internal browser queue (the number of concurrent connection is limited so, in case of many requests done by the page some need to wait)

---

1. Here is a place showing how we can get the start time of the first request firstRequestStartedMs
   https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/RequestListContent.js#422

We need to implement the same connect method in the TimingsPanel to get the same property
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/TimingsPanel.js#167

Don't forget to also update the list of props just like the RequestListContent does
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/RequestListContent.js#78

2. Here is the place in TimingsPanel where we are reading props
   https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/TimingsPanel.js#97

And here is the calculation:

const { eventTimings, totalTime, startedMs } = this.props.request;
const relativeStartedMs = startedMs - this.props.firstRequestStartedMs;
const queuedMs = eventTimings.timings.blocked;

Honza

Comment 9

[Hayden Huang]

Hi Honza, I just made some implementations, and for now the queue and start time shows like the snapshot Florens Verschelde given above, but I still have some question.

First, you mentioned we need to implement connect method in TimingPanel just like RequestListContent.js, but I have no ideal what this for and how to do this.

Second you said first request has start time 0 and I am not sure about it, because when I test on chrome, the first request gets queues time 0 instead of start time, can you confirm which is right?

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Hayden Huang: I just found a dup of this bug report and I need to close this one, I am sorry about that!
I didn't notice that somebody else is actually working on the same already (and started before you).

However, if you are still interested in good first bug, here is a list:
https://bugs.firefox-dev.tools/?easy&tool=network

Since it's your first contribution I can recommend e.g.: Bug 1593919 - Move RequestList components into a sub directory
It's relatively small refactoring of the code base, which is usually good for learning the code base.
What do you think?

Honza

Comment 11

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Hayden Huang from comment #9)

Second you said first request has start time 0 and I am not sure about it, because when I test on chrome, the first request gets queues time 0 instead of start time, can you confirm which is right?

Good catch, looks like Chrome does it the right thing here.
Honza