How to get time in the Network timeline when the request was started

[msh...@gmail.com]

I wonder is there a way to get time value in the Network timeline when the request has been started. Using timeline chart it hard to get the exact value. My task to check if the ajax callbacks triggering in the specific time interval.

[Pavel Feldman]

You could use Timeline panel for that.

Pavel

[msh...@gmail.com]

That may work but due to too much info and lack of filtering it is hard to work with that panel (or you need time to learn) for such a simple task I need. Well, keep using Fiddler :-(

 

What I need is a very simple enhancement on Network panel (you have this data but you need just to display it!):

1. When you hover mouse over a bar in the timeline the popup appears with the following data: Blocking - Sending - Waiting - Receiving. Please add here two more: "Start Time" and "End Time"

2. Add these two columns "Start Time" and "End Time" to the grid. You may hide them by default and provide the column chooser.

 

Thanks.

[Pavel Feldman]

That sounds good. Please file a bug on it using http://crbug.com/new !

Regards

Pavel

[Nitin Surana]

It's 2015 but still couldn't find a way to see the startTime and endTime of a request.

[Moshe Shaham]

this feature can be very helpful in debugging network problems. right now it's impossible to get the accurate timestamp of the request start time

On Thursday, October 18, 2012 at 9:39:27 PM UTC+3, msh...@gmail.com wrote:

I wonder is there a way to get time value in the Network timeline when the request has been started. Using timeline chart it hard to get the exact value. My task to check if the ajax callbacks triggering in the specific time interval.

This email and any files transmitted with it contain information from Idomoo which may be privileged and confidential and intended solely for the use of the addressee. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited; please notify us immediately by an email reply and delete it from your system. Idomoo accepts no liability for any personal views or opinions expressed in this email. Email transmission cannot be guaranteed to be secure or error-free. Idomoo therefore is not liable for any errors or omissions in the contents of this message, which arise as a result of email transmission.

[dex]

Agreed, it would be helpful to have this data in the network section in dev tools. I followed the link above to file a bug report but that didn't seem appropriate when I got in and looked at the details for that process. I didn't have any luck finding previous reports of this issue in the myriad of entries already there. This seems more like a feature enhancement so I'll try to figure out how to put in a request for that.

[dex]

I added a bug report for this as I wasn't able to find one already, open or closed.

https://bugs.chromium.org/p/chromium/issues/detail?id=694596

[Paul Irish]

This is now fixed in Canary as of last week:

CL: https://codereview.chromium.org/2057243003

[Nate Dudenhoeffer]

I am not seeing this functionality using Canary version 59.0.3064.0. I am using the remote inspect feature.

[Nate Dudenhoeffer]

I see now this is functional in the normal developer tools. Thanks Paul for the update.

Is this functionality still missing from the remote inspect feature, or will it be available when the remote target has a newer build? In my case it is the Android System Webview.

[Ch Ho]

I've seen the feature shown above, which shows the request start time.

However, the time is shown relative to the start of the navigation.

In my use case, I noticed a console log message (with timestamp 11:10:20.606) from my application that said an xhr response was malformed (json truncated, apparently).  However, I wasn't able to tie that to a particular network request because I couldn't find the timestamp.

I tried to work around this by adding an extra header column of 'Date', but found the server is reusing the 'Last-Modified' value as the 'Date' value.  Even if it gave the current time, it's from a clock of unknown accuracy, and it doesn't show milliseconds.

Also, the last number on the popup should probably be labeled "Total:", and it would be good to have a row that shows the same time as you can see when hovering over the first box of the request on the graph (460ms), which looks like is time from connection start to the end of the waiting (TTFB) period (458.80ms).

Thanks!

[Matt C. Wilson]

Wow, I am surprised this feature does not exist in the Dev Tools, but also surprised that I've not needed it till now.

We are trying to pinpoint a session authentication issue that is happening sporadically but consistently for a customer.  Getting accurate diagnostic logs from them has been too challenging, so we are trying to replicate the behavior by leaving a Chrome browser open in an auto-refresh mode and just collect the HTTP traffic in the Network tab.

Unfortunately, there are no absolute timestamps (1/24/2020 @ 16:43:02.134) anywhere that I can find, only relative durations ( 21 ms elapsed ).

Turning on a performance recording and then saving a profile does include unix timestamps in the JSON output.  But those logs are far too voluminous to leave on overnight as a means of capturing an absolute time of occurrence if we see the issue.

Am I missing something?  Is there any way to see an actual date and time that a request was issued, or a response was received, or both?

Thanks,

Matt  

[PhistucK]

You can get the new Date(performance.timing.connectStart) (or similar) for absolute timestamps.

There is also resource timing, I do not remember off hand how to get this data from it, but I believe it should be possible.

Also, performance.timeOrigin is probably the same point as the Developer Tools starting point, so you can might be able to summate it and the relative ones to get absolute ones.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chrome DevTools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/a74faae4-e8c6-4fde-86b7-cc65321fc1c9%40googlegroups.com.

[Matt C. Wilson]

Thanks for the quick reply. 

Not sure what you're referring to - are you suggesting that, after leaving a network capture open for some time, running that code in the console to get the "page load" / start-of-capture timestamp, and then computing timestamps against it?

That's... a lot of work.

Fortunately, it looks like request date-times are available in the Response headers Date field, generally, and are also captured in the HAR export.

That's good enough for my purposes.  A UI toggle for absolute timeline vs. relative timeline, or a "timestamp range" filter option, would be super handy.  

On Friday, January 24, 2020 at 6:35:18 PM UTC-5, PhistucK wrote:

You can get the new Date(performance.timing.connectStart) (or similar) for absolute timestamps.

There is also resource timing, I do not remember off hand how to get this data from it, but I believe it should be possible.

Also, performance.timeOrigin is probably the same point as the Developer Tools starting point, so you can might be able to summate it and the relative ones to get absolute ones.

☆PhistucK

On Sat, Jan 25, 2020 at 1:29 AM Matt C. Wilson <matthew...@gmail.com> wrote:

Wow, I am surprised this feature does not exist in the Dev Tools, but also surprised that I've not needed it till now.

We are trying to pinpoint a session authentication issue that is happening sporadically but consistently for a customer.  Getting accurate diagnostic logs from them has been too challenging, so we are trying to replicate the behavior by leaving a Chrome browser open in an auto-refresh mode and just collect the HTTP traffic in the Network tab.

Unfortunately, there are no absolute timestamps (1/24/2020 @ 16:43:02.134) anywhere that I can find, only relative durations ( 21 ms elapsed ).

Turning on a performance recording and then saving a profile does include unix timestamps in the JSON output.  But those logs are far too voluminous to leave on overnight as a means of capturing an absolute time of occurrence if we see the issue.

Am I missing something?  Is there any way to see an actual date and time that a request was issued, or a response was received, or both?

Thanks,

Matt  

On Thursday, April 5, 2018 at 2:42:48 PM UTC-4, Ch Ho wrote:

I've seen the feature shown above, which shows the request start time.

However, the time is shown relative to the start of the navigation.

In my use case, I noticed a console log message (with timestamp 11:10:20.606) from my application that said an xhr response was malformed (json truncated, apparently).  However, I wasn't able to tie that to a particular network request because I couldn't find the timestamp.

I tried to work around this by adding an extra header column of 'Date', but found the server is reusing the 'Last-Modified' value as the 'Date' value.  Even if it gave the current time, it's from a clock of unknown accuracy, and it doesn't show milliseconds.

Also, the last number on the popup should probably be labeled "Total:", and it would be good to have a row that shows the same time as you can see when hovering over the first box of the request on the graph (460ms), which looks like is time from connection start to the end of the waiting (TTFB) period (458.80ms).

Thanks!

On Thursday, April 6, 2017 at 6:50:39 AM UTC-7, Nate Dudenhoeffer wrote:

I see now this is functional in the normal developer tools. Thanks Paul for the update.

Is this functionality still missing from the remote inspect feature, or will it be available when the remote target has a newer build? In my case it is the Android System Webview.

--
You received this message because you are subscribed to the Google Groups "Chrome DevTools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.