Re: navigationStart and the actual start of the navigation

On 7/1/14, 11:58 AM, Przemysław Pietrzkiewicz wrote:
>     That's correct, but there is no attribute that corresponds to "after
>     the previous page has finished doing whatever it's doing" apart from
>     navigationStart.
>
> But we'd be keeping this bit, right? The part "This attribute must
> return the time immediately after the user agent finishes prompting to
> unload the previous document." would stay at it is.

Yes, but if there was no prompt then this would be completely ignored.

So if the previous page has a 2s sync XHR to save state in beforeunload 
but doesn't ever return a string so the user is not prompted, then the 
2s would just get included in the timing of the new page, with no way 
for the new page to tell that's where the 2s came from.

> The users don't care about the difference, but also they will be not
> using the API.

Sure.  So what do people who are planning to use the API care about?

> The developers might be interested in knowing what takes the time
> between clicking a link (or confirming the beforeunload handler, or
> setting window.location, etc.) and completing the load.

I think you just lumped together different things.  In particular these 
are not mutually exclusive.  The user clicks a button.  Some time later 
there is a click event on a link.  Some time after that, the click 
handlers are done firing and the browser decides it should try 
navigating.  It locates the target browsing context, creating it if 
needed.  then it fires beforeunload, so some more script runs.  It may 
or may not return a string; if it does the UA prompts the user.  If it 
does not return a string or if the user allows the navigation, a fetch 
is performed.

The fundamental question is where in that sequence of events we should 
consider the navigation to have "started", right?  What would the 
consumers of this API want to measure here?  Does it matter whether the 
old and new page are same-origin?

> Current wording of the spec leaves parts of that time not represented in the recorded
> metrics for the case of navigations that require a new browsing context.

Define "that time"?

> Taking a step back, current wording defines navigationStart as:
> - time of confirming the beforeunload prompt if there is one

The current wording defines navigationStart as the time when "prompting 
to unload" finishes.  This may not involve any prompts at all; it's just 
an algorithm that fires some events on a bunch of documents, and if 
those events have string returnValues may prompt the user before the 
algorithm terminates.  I suggest following the link in the spec and 
reading the algorithm.

> - unclear what otherwise, as the rest of the spec mentions "if there's
> no previous document" and you argue that there is always one

There is always a previous document, except for initial about:blank.  So 
per current spec for initial about:blank getting navigationStart will 
return the same thing as getting fetchStart.  This part is not 
well-defined indeed, because initial about:blank is not actually fetched 
and fetchStart explicitly refers to "fetch".

> Proposed definition of navigationStart is:
> - time of confirming the beforeunload prompt if there is one
> - time of starting the navigation (as seen by the UA) otherwise

1)  There may be multiple prompts.
2)  If there is only a single prompt, it may happen quite a bit before
     "prompt to unload" is done.
3)  This whole discussion is about defining what "time of starting
     the navigation" is, so your second item is tautological as far as
     I can tell.

> Are you worried about any concrete use case that would be broken by such
> change?

I'm worried about the change not actually having a defined behavior not 
really having clear goals.

-Boris

Received on Tuesday, 1 July 2014 16:27:59 UTC