Re: navigationStart and the actual start of the navigation

I'm finding it hard to define the navigationStart in a way that would
capture all of the cases discussed above. The HTML spec is deliberately
imprecise about actions that cause navigations[1]:

"Certain actions cause the browsing context to navigate to a new resource.
(..) A user agent may provide various ways for the user to explicitly cause
a browsing context to navigate, in addition to those defined in this
specification. For example, following a hyperlink, form submission, and the
window.open() and location.assign() methods can all cause a browsing
context to navigate."

It seems that in order to capture delays like identifying the frame to
navigate when a hyperlink is clicked, we would need to define the recording
start time separately for each scenario that causes a browser to navigate.
Not too appealing...

What we could do, is to move the navigationStart to the beginning of the
browser context navigation, for instance by stating:

navigationStart - This attribute must return the starting time of the
browsing context navigation that is responsible for this document load,
unless a document unload prompt was displayed to the user during the
navigation. If such prompt was displayed, this attribute must return the
time of confirming the navigation by the user.

Note that we're doing the following:

- we're talking *browser context* navigation here, not *document*
navigation. We're taking this one level higher, and the tricky condition:
"If there is no previous document, this attribute must return the time the
current document is created." is no longer needed.
- we're aligning the definition with the current statement of the High
Resolution Time[2], which defines the time origin as the beginning of
"navigation". The spec mentions "document navigation", but the hyperlink
actually leads to the browsing context navigation. I think we could change
the wording to mention "browser context navigation" there as well.
- we're capturing the time needed for the onbeforeunload handlers
- we're capturing the time needed to spawn the renderer process for a new
browsing context (as the navigation can start before the renderer is ready
for the initial about://blank)

Boris, Arvind, others, wdyt?

[1] http://www.w3.org/TR/html5/browsers.html#navigate
[2]
https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview.html#sec-time-origin

Cheers,
Przemek


On Fri Sep 05 2014 at 8:15:00 PM Arvind Jain <arvind@google.com> wrote:

> +plh
>
> Philippe, what should we do here? Seems like updating Navigation
> Timing 1 is the right approach.
>
> On Wed, Aug 27, 2014 at 11:36 AM, Przemysław Pietrzkiewicz
> <ppi@google.com> wrote:
> > Hello,
> >
> > Having taken a look at Navigation Timing 2 and friends, it seems that
> it's
> > not that clear where (to which spec) a change of navigation start time
> > definition would belong to. Let me explain.
> >
> > I understand that Navigation Timing 1 is pretty much in maintenance mode
> and
> > we would be making the change to Navigation Timing 2. However, as
> Navigation
> > Timing 2 is based on High Resolution Time, it does not define (or even
> > contain) the "navigationStart" attribute - instead, being
> > DOMHighResTimeStamps, its attributes are relative to the navigationStart
> of
> > the original NavigationTiming spec, as required by the High Resolution
> Time
> > spec.
> >
> > So in order to have the change applied to Navigation Timing 2, we'd need
> to
> > either change the definition of DOMHighResTimeStamps in High Resolution
> Time
> > (severing the relation with navigationStart from Navigation Timing 1), or
> > actually make the change in Navigation Timing 1.
> >
> > What do you guys think?
> >
> > Cheers,
> > Przemek
> >
> >
> > On Wed, Jul 23, 2014 at 7:48 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >>
> >> On 7/23/14, 1:07 PM, Przemysław Pietrzkiewicz wrote:
> >>>
> >>> Agreed; I think that for some applications "most" will not be good
> >>> enough though.
> >>
> >>
> >> My point was that typically the work beforeunload does will be perceived
> >> as part of the page load by the user.
> >>
> >>
> >>> Maybe recording navigationStart earlier but providing new
> >>> intermediate points so that it's possible to exclude the onbeforeunload
> >>> event if needed would be reasonable?
> >>
> >>
> >> Sure.  Or, again, resetting the navigationStart time if a prompt is
> >> actually shown.
> >>
> >>> Wdyt?
> >>
> >>
> >> Doesn't seem completely insane.
> >>
> >>
> >>> PS I'm ooo until the 4th of August with limited email access, apologies
> >>> for any inconvenience.
> >>
> >>
> >> I'm likewise out Aug 5-19, fwiw.
> >>
> >> -Boris
> >>
> >
>