On Wed, Mar 23, 2011 at 8:43 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote: > 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. duh, you are right. late night is not a good time to think... > > "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 16:58:00 UTC