- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 11 Jul 2012 19:14:17 -0400
- To: Jatinder Mann <jmann@microsoft.com>
- CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
On 7/11/12 1:39 PM, Jatinder Mann wrote: > I believe the editor was trying to capture the scenario when traversing from a bfcache What do you mean by "traversing from a bfcache"? > and not hitting the network, we shouldn't update the timing data for > that page from when it had initially hit the network. Let me see if I can rephrase the desideratum. "When loading a page from bfcache, the timing data on the resulting Window object should be the same as the timing data when the page was initially placed in bfcache." Is this limited to bfcache-like setups, or does it apply to other history loads that might be coming from a cache but only get the source, not the DOM? > The definition of navigation, http://www.w3.org/TR/html5/single-page.html#navigate, which we are planning to reference in Navigation Timing, doesn't seem to explicitly call out session history traversal. That's not a definition. That's a processing model. The "definition", insomuch as there is one at all, lies in which places say that the UA must "navigate". The relevant text for our purposes here seems to be at http://www.w3.org/TR/html5/single-page.html#traverse-the-history and says, in step 1: If there is no longer a Document object for the entry in question, the user agent must navigate the browsing context to the location for that entry to perform an entry update of that entry, and abort these steps. In the bfcache case there is a Document object for the entry (just like for an anchor scroll), so there is no navigation happening here in HTML5 terms. -Boris
Received on Wednesday, 11 July 2012 23:14:48 UTC