- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 23 Mar 2011 17:43:24 +0200
- To: Zhiheng Wang <zhihengw@google.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Tony Gentilcore <tonyg@google.com>, public-web-perf@w3.org, jmann@microsoft.com, Nic Jansma <njansma@microsoft.com>
On 03/23/2011 10:14 AM, Zhiheng Wang wrote: > Ollis does remind me a question though. Even though > performance.timing should not change > when using bfcache (or in cases like the recently implemented chrome > prefetch), the current draft > implies that the navigation.type will change to BACK_FORWARD, which > could confuse the > js as well. > > maybe navigation.type should remain the same in case of bfcache as well? Based on the current draft, .type should not change. "In those cases, the window.performance.timing and window.performance.navigation objects must not be altered during the navigation." I still don't quite understand why one kind of navigation (navigation from a page to another page in bfcache) shouldn't alter the .performance.* objects. But if others think that is the behavior we want, that is ok to me. I do note that Navigation Timing tests don't allow this behavior. They assume that when history.forward()/.back() are used, the navigation.type is TYPE_BACK_FORWARD -Olli > > cheers, > Zhiheng > > > > > And writing tests for BACK_FORWARD becomes really hard, > > since you don't know what value browser returns in .navigation.type. > > Some browsers may return NAVIGATION (because they have bfcache), some > > may return BACK_FORWARD. > > The fact that the test has to be a bit more intelligent does not seem > like a reason to complicate the feature exposed to web developers. > > > Also, that kind of behavior would actually prevent one > > kind of performance timing - BACK_FORWARD + cached DOM. > > What timing is there to do? > > / Jonas > >
Received on Wednesday, 23 March 2011 15:44:05 UTC