Closed Bug 1580431 Opened 5 years ago Closed 5 years ago

Start time, end time of request


(DevTools :: Netmonitor, enhancement, P3)



(firefox72 fixed)

Firefox 72
Tracking Status
firefox72 --- fixed


(Reporter: ruturaj, Assigned: ruturaj)


(Blocks 1 open bug)


(Keywords: dev-doc-complete, parity-chrome)


(5 files, 1 obsolete file)

Attached image chrome-start-time.png

Recently I was debugging some network calls, latency, etc. I found that Firefox misses an essential measurement of the network request (atleast not shown) - that of the start time / timestamp of the network request. Sometimes it is useful to see when the request started (ie. 1.7s into the page hit/refresh, and then at what time it successfully got delivered, ie. 2.3s). This is very helpful when measuring timelines of the page or timed events.

Chrome currently does have the timestamp displayed, it shows the total elapsed time for the request as well. It shows the data at 2 levels

  • The hover card when the mouse is moved over the network timing graph
  • The Timing tab on clicking the request (as in the 1st attachment)

We too should have something similar

  • On the hover state, show in the tooltip (that should suffice)
  • On the clicked state, we already have the Timings tab.

I tried searching in BMO, however couldn't find the bug, so filing it here. I've already checked the developer edition there is no such enhancement in it.

I'm willing to work on this one :)

Thanks for the report!

Yes, agree this looks like useful info to display to the user.

@Harald, any comments for this?


Priority: -- → P3
Flags: needinfo?(hkirschner)

Absolutely, that there is no way to find out right now makes dependency analysis a lot harder.

We should also file a bug for the hover card if we don't have one yet.

Flags: needinfo?(hkirschner)
Keywords: parity-chrome

Bug for the Hover card : bug 1580493


No longer blocks: 1580493

Thanks, Honza!
Let me start digging into this.

  • Rutu
Assignee: nobody → ruturaj


I have few questions,

  • the Started at ie 1.7s, it should calculated relative to which event? The timings.RESPONSE_COMPLETE.last of the very first request OR the dom.ready event ?
  • How to keep tab of the first request
    • Using a closure of NetworkObserver fn, which could ensure a static like member. The above event will trigger it to be true, and that member's response_complete.last or dom.ready would be considered epoch.
    • Or is there any other place for me too look ?


Flags: needinfo?(odvarko)
Attached file WIP: Bug #1580431 (obsolete) —

Added queued at time in TimingsPanel

Attached image wip-queued-at.png

This is a WIP queued at UI

@Ruturaj: there is a dup report of this feature where I was posting detailed instructions how to fix it.

Please look at the following comments:


Flags: needinfo?(odvarko)

Just adding Honza's comments from bug#1471249

Thanks for the report!

Some instructions for anyone interested in fixing this bug:

The Timings panel is represented by TimingsPanel component and is rendered here

All timings data are accessible form props using this.props.request.eventTimings

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)

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


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)

Here is a place showing how we can get the start time of the first request firstRequestStartedMs

We need to implement the same connect method in the TimingsPanel to get the same property

Don't forget to also update the list of props just like the RequestListContent does

Here is the place in TimingsPanel where we are reading props

And here is the calculation:

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


Attached patch 1580431-1.patchSplinter Review
Attachment #9104586 - Attachment is obsolete: true
Pushed by
Start time, end time relative to first request in the Timings Panel. r=Honza.
Attachment #9104586 - Attachment is obsolete: false
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72
Flags: needinfo?(odvarko)

Yes, Karen can help with that.

Flags: needinfo?(jswisher)
Keywords: dev-doc-needed

Doc changes are being tracked in

Flags: needinfo?(jswisher)

Thanks, do let me know how could I be of your help.

Flags: needinfo?(odvarko)
Attachment #9104586 - Attachment is obsolete: true
Regressions: 1601911

I've documented this feature; see for the full details.

Thanks Chris!

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