Closed Bug 1471249 Opened 2 years ago Closed 4 months ago

Add Start, End And Duration To Timings Tab

Categories

(DevTools :: Netmonitor, enhancement, P3)

62 Branch
enhancement

Tracking

(firefox62 affected)

RESOLVED DUPLICATE of bug 1580431
Tracking Status
firefox62 --- affected

People

(Reporter: dave.hawkins, Assigned: hongda.huang)

Details

(Keywords: dev-doc-needed, good-first-bug)

Attachments

(2 files)

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.

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.

Attached image 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.

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

Flags: needinfo?(odvarko)

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

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(odvarko)
Keywords: good-first-bug
Priority: -- → P3

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?

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

Assignee: nobody → hongda.huang
Status: NEW → ASSIGNED

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

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

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

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?

@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

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1580431

(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

You need to log in before you can comment on or make changes to this bug.