Re: navigationStart and the actual start of the navigation

Thanks for following up.

The difference I had in mind is that existing doc's onbeforeunload handler
can still cancel the navigation, and the navigation is stalled while the
prompt is being displayed. It doesn't seem useful to include the time we
wait for confirmation in the performance metrics. One could argue that in
presence of onbeforeunload prompt, it is confirmation of the prompt that
actually triggers the navigation.

If the goal of this spec is to represent the user-perceivable time of
performing the navigation, then I think we should include both creation of
the new browsing context and finding the correct subframe to navigate.
Unless an unbeforeunload prompt is displayed to the user, in which case the
confirmation in the prompt should probably override.

I thought this was the intention of the current wording:

"This attribute must return the time immediately after the user agent
finishes prompting to unload the previous document. If there is no previous
document, this attribute must return the time the current document is
created."

It's correct that according to the spec (that states that every new
browsing context starts on about:blank and navigates from there), there is
always a previous document. So maybe the right fix would be:

"This attribute must return the time immediately after the user agent
finishes prompting to unload the previous document. If no such prompt is
displayed, this attribute must return the time of the user action that
triggered the navigation."

Wdyt?

Cheers,
Przemek





On Fri, Jun 27, 2014 at 5:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/27/14, 11:31 AM, Przemysław Pietrzkiewicz wrote:
>
>> I see, thanks for the explanation. In this case, maybe we could go for:
>>
>> "This attribute must return the time when the user agent determines that
>> the navigation will happen. For navigations from documents other than
>> the initial about:blank of the browsing context, this is the time when
>> the user agent finishes prompting to unload the previous document."
>>
>
> Here's a question.
>
> Say I click a link like this: <a target="foo" href="bar">Click me</a>.
>
> The UA decides that a navigation will happen at the point when I click.
>  Then it has to go look for a named target (which might take a while,
> depending on how many frames are reachable from that document).  If it
> finds one it will prompt to unload that document; if not, it will open a
> tab/window/whatever.
>
> Should the time needed to find the named target be considered when
> deciding when navigationStart is?  I guess it can't be if we want to
> exclude the time it takes to fire beforeunload handlers...
>
>
>  Actually, the second sentence might be redundant - the time when the
>> user agent determines that the navigation will happen in the presence of
>> a document already loaded in the browsing context is the end of
>> beforeunload.
>>
>
> OK...
>
> But initial about:blank can also have beforeunload handlers, note, though
> not in the case when the UA is creating a new browsing context and then
> immediately navigating it.
>
> I guess an important question is this: how is browsing context creation
> fundamentally different from beforeunload handler execution in terms of
> whether it should be included in the time taken to load?  It sounds like
> you want to include the former but exclude the latter, right?
>
> -Boris
>
> P.S. "when the user agent determines that the navigation will happen" is a
> non-testable requirement, fundamentally; UAs can do whatever the heck they
> want with it.
>