- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 01 Jul 2014 12:27:28 -0400
- To: Przemysław Pietrzkiewicz <ppi@google.com>
- CC: public-web-perf@w3.org
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