W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2013

RE: navigationStart in NavigationTiming

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 1 May 2013 16:27:23 +0000
To: "'arvind@google.com'" <arvind@google.com>, "'public-web-perf@w3.org'" <public-web-perf@w3.org>
Message-ID: <addee2dabc794fa7a7540a9b786bc232@BLUPR03MB065.namprd03.prod.outlook.com>
Can you submit a test case? In this example, redirectStart and redirectEnd have been zero'd out. An example where they aren't zero'd out might be more helpful.

Thanks,
Jatinder

From: Arvind Jain [mailto:arvind@google.com]
Sent: Tuesday, April 30, 2013 7:08 PM
To: public-web-perf
Subject: navigationStart in NavigationTiming

I've a question about the definition of navigationStart in the specification (http://www.w3.org/TR/navigation-timing/#dom-performancetiming-navigationstart)

It says:
This attribute must return the time immediately after the user agent finishes prompting to unload<http://www.w3.org/TR/html5/browsers.html#prompt-to-unload-a-document> the previous document. If there is no previous document, this attribute must return the same value as fetchStart<http://www.w3.org/TR/navigation-timing/#dom-performancetiming-fetchstart>.

The second part of this statement seems odd to me. In case the document in question has redirects (e.g. same origin redirects), the value of navigationStart will be very different if there was a previous document that had to be unloaded vs. not.

The difference doesn't make sense.

This line was added on Oct 14. 2010. There is one discussion a day before that
http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0024.html
which seems to have better text for this but the spec has something else.

I think this inconsistency happened as we revised the definition of navigationStart, and we forgot to update the second part of the definition.

I checked Chrome and it does the right thing - I load http://en.wikipedia.org/ in a new tab and it has a same origin redirect. navigationStart is not equal to fetchStart in this case, and in fact occurs before redirectStart which in my opinion is correct behavior.

How do we fix this?

Arvind
Received on Wednesday, 1 May 2013 16:30:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC