ResourceTiming duration should be non-0 for failed DNS, TCP, SSL

NEW
Assigned to

Status

()

defect
P3
normal
3 months ago
2 months ago

People

(Reporter: nic, Assigned: valentin)

Tracking

64 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-triaged])

(Reporter)

Description

3 months ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Load a resource that is aborted due to a network error such as DNS, TCP or SSL failure.

Fetch the resource from ResourceTiming.

Example: https://nicj.net/dev/resourcetiming/error-resources.html

Actual results:

For DNS lookup failures, TCP connection failures, SSL handshake failures, etc, I would expect the startTime and respondEnd to reflect the start and end of the attempted connection, and be different from each other.

Similarly, I would expect duration to be non-0 (reflect how long it took for DNS, TCP, SSL, etc to fail).

Instead, we see that startTime == responseEnd and duration == 0.

Expected results:

On getting, the responseEnd attribute MUST return as follows:
The time immediately after the user agent receives the last byte of the response or immediately before the transport connection is closed, whichever comes first. The resource here can be received either from relevant application caches, local resources, or from the server.
The time immediately before the user agent aborts the fetch due to a network error.

https://www.w3.org/TR/resource-timing-2/#dom-performanceresourcetiming-responseend

Component: Untriaged → Networking
Product: Firefox → Core

Valentin, can you confirm this?

Flags: needinfo?(valentin.gosu)

The priority flag is not set for this bug.
:selenamarie, could you have a look please?

Flags: needinfo?(sdeckelmann)
Assignee: nobody → valentin.gosu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(sdeckelmann)
Priority: -- → P3
Whiteboard: [necko-triaged]
You need to log in before you can comment on or make changes to this bug.