Re: navigationStart and the actual start of the navigation

Ah, good catch, thanks! Taking not-user actions into account we'd have
something like:

"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 event that triggered
the navigation."

I think a reasonable goal for the parameter would be to capture the
duration of the navigation *as perceptible by the user* (to the extent of
feasibility, of course). If we exclude things like locating the subframe to
navigate or spinning up new browsing context, we can have navigations that
feels sluggish but are reported as fast.

What do you think?

Cheers,
Przemek


On Mon, Jun 30, 2014 at 6:16 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/30/14, 9:12 AM, Przemysław Pietrzkiewicz wrote:
>
>> "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."
>>
>
> That at least seems like a possibly useful quantity.  It doesn't address
> navigations not triggered by user actions (e.g. <meta refresh>, location
> sets off timers, etc).
>
> Rigorously defining things like "the user action that triggered the
> navigation" in a future-proof way might be tough too...
>
> Maybe it's worth putting in the work to get this more complex model
> defined, of course.  It really comes back to what the navigation timing
> bits are trying to measure.  Are they measuring the time somewhat under the
> control of the target server, or things completely outside its control
> (like beforeunload dialogs on previous pages or the time it takes a browser
> to spin up a new rendering context)?
>
> -Boris
>