New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: Fixed
Closed: Dec 12
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 449224

Sign in to add a comment

Issue 404501: [Resource Timing] secureConnectionStart is 0 but it should be a timestamp

Reported by, Aug 17 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36

Steps to reproduce the problem:
1. Go to any https site, eg, .
2. Load the same website again.
3. Open console and enter performance.timing.secureConnectionStart.
==> Note that the value is "0".

What is the expected behavior?
According to the spec this should be a timestamp since the secureConnectionStart property *is* available and the scheme of the current page *is* HTTPS.

What went wrong?
It looks like the bug occurs when an existing TCP connection is being re-used (note that connectStart == connectEnd which implies a re-used connection). But in this situation secureConnectionStart should == connectStart. Because of this bug people tracking SSL metrics would expect that if the scheme *is* HTTPS and secureConnectionStart is not "undefined" then they should be able to get the SSL connect time from (connectEnd - secureConnectionStart) but in fact this will return an extremely large value. This erroneous metric will likely go undetected and invalidate aggregate SSL stats.

Here's the relevant paragraph from the spec ( ): "This attribute is optional. User agents that don't have this attribute available MUST set it as undefined. When this attribute is available, if the scheme of the current page is HTTPS, this attribute MUST return a DOMHighResTimeStamp with a time value equal to the time immediately before the user agent starts the handshake process to secure the current connection. If this attribute is available but HTTPS is not used, this attribute MUST return zero."

It's possible you could interpret secureConnectionStart as being not available - in which case its value should be undefined. But the spec is clear that the only time it should be zero is when HTTPS is not used, which is not the case here.

Did this work before? N/A 

Chrome version: 36.0.1985.143  Channel: stable
OS Version: OS X 10.9.4
Flash Version: Shockwave Flash 14.0 r0

Bug also occurs in Chrome Canary (28).
32.3 KB View Download

Comment 1 by, Aug 18 2014

The same issue occurs for Resource Timing.
28.9 KB View Download

Comment 2 by, Sep 5 2014

Labels: Needs-Feedback
stevesoudersorg,,Thanks for your response.Are you still seeing the same issue with Latest Canary :39.0.2146.0 and also with Latest stable :37.0.2062.103?
Few such issues has been fixed with latest chrome version,if you still find the same we can go ahead for further triageing it.
Thanks in Advance.

Comment 3 by, Sep 5 2014

still happens

Comment 4 by, Sep 26 2014

Able to repro the issue on mac 10.9 chrome version 39.0.2169.3 and stable 37.0.2062.122 - 0 displayed in the console for performance.timing.secureConnectionStart

Please find the screenshots

The same is observed on win also. Could you please confirm the actual and expected behaviors in latest stable
Screen Shot 2014-09-25 at 11.46.43 PM.png
105 KB View Download
Screen Shot 2014-09-25 at 11.49.14 PM.png
64.8 KB View Download

Comment 5 by, Sep 30 2014

Could you please review the C#4 and update the thread.

Comment 6 by, Dec 23 2014

Labels: -OS-Mac -Needs-Feedback OS-All M-41 m-41
Status: Untriaged
Triaging this for further investigation.

This is reproducible across Linux and Windows-7 on latest M-41(41.0.2257.0) as well & has been behaving the same since older chrome version(27.0.1449.0 (Official Build 189738)).

Comment 7 by, Dec 23 2014

Labels: -m-41

Comment 8 by, Jan 15 2015

Labels: -M-41 M-42 MovedFrom-41
Moving all non essential bugs to the next Milestone.

Comment 9 by, Jan 15 2015

FWIW, related:  -- hopefully fixing that (which is a bigger issue) would address this as well.

Comment 10 by, Mar 3 2015

Labels: -M-42 MovedFrom-42
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

Comment 11 by, Mar 13 2015

[Automated message] This issue does not seem to be a V8 issue. The label Cr-Blink-JavaScript will be removed next week. The label Cr-Blink will be added instead. If you think that this issue is correctly labeled as a V8 issue please contact hablich@.

Comment 12 by, Mar 19 2015

Labels: -Cr-Blink-JavaScript NotV8 Cr-Blink
[Automated message] This issue does not seem to be a V8 issue. The label Cr-Blink-JavaScript is removed. The label Cr-Blink is added instead. If you think that this issue was correctly labeled as a V8 issue please contact hablich@.

Comment 13 by, Nov 10 2015

Labels: -Cr-Blink Cr-Blink-PerformanceAPIs

Comment 14 by, Mar 2 2016

I still see this behavior in Stable (48.0.2564.116 (64-bit)) and Canary (51.0.2663.0 canary (64-bit)).

Comment 15 by, Mar 11 2016

Status: Available (was: Untriaged)

Comment 16 by, Jul 15 2016

Labels: Hotlist-PerformanceAPIs

Comment 17 by, Apr 12 2017

Blockedon: 449224

Comment 18 by, Aug 14 2017

Summary: [Resource Timing] secureConnectionStart is 0 but it should be a timestamp (was: secureConnectionStart is 0 but it should be a timestamp)

Comment 19 by, Sep 7 2017

Components: Blink>PerformanceAPIs>ResourceTiming

Comment 20 by, Sep 7 2017

Components: -Blink>PerformanceAPIs

Comment 21 by, Feb 28 2018

Still blocked on  issue 449224 .

Comment 22 by, Feb 28 2018

Actually, it looks like  issue 449224  has been addressed, so this isn't blocked.

Comment 23 by, Jun 27 2018

Status: Assigned (was: Available)
Note that performance.timing is now deprecated [1]. The bug still shows up in ResourceTiming and NavigationTiming. I have a tentative fix but the two specs say different things about the value of secureConnectionStart when the connection is not secure, so I'll file a bug about that.


Comment 24 by, Oct 15

Hey Nicolas - CSM triage here. Where are we at on this bug?

Comment 26 by, Dec 7

Project Member
The following revision refers to this bug:

commit c92f6ff28e1c27cd004201f48fe9e2eb16bbc749
Author: Nicolas Pena <>
Date: Fri Dec 07 22:38:42 2018

Fix secureConnectionStart when connection is reused

Per ResourceTiming spec, if a connection is reused
then secureConnectionStart must return fetchStart, not 0.

Bug:  404501 
Change-Id: Ica208c98cfea0afa9dd22e4edc83cc3c430c219f
Commit-Queue: Nicolás Peña Moreno <>
Reviewed-by: Yoav Weiss <>
Cr-Commit-Position: refs/heads/master@{#614849}

Comment 27 by, Dec 12

Status: Fixed (was: Assigned)
I've fixed this for Navigation Timing. That is, performance.getEntriesByType('navigation'). performance.timing is deprecated and this has not been fixed for that API (the reuse connection flag is not present there).

Sign in to add a comment