W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2011

Re: [NavigationTiming] few comments

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 23 Mar 2011 00:47:36 +0200
Message-ID: <4D892708.1060108@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
CC: Tony Gentilcore <tonyg@google.com>, public-web-perf@w3.org, jmann@microsoft.com, Nic Jansma <njansma@microsoft.com>, Zhiheng Wang <zhihengw@google.com>
On 03/23/2011 12:32 AM, Jonas Sicking wrote:
> On Tue, Mar 22, 2011 at 3:05 PM, Tony Gentilcore<tonyg@google.com>  wrote:
>>> How do current implementations handle cached DOM + back-forward?
>>
>> WebKit has a bfcache called PageCache, but it is disabled in Chrome.
>> Since it is moot there, I haven't payed attention to the details here.
>> Nic or Jatinder can probably comment on what IE does here. If they
>> don't use it either, mozilla is probably the first implementation with
>> a bfcache and you might suggest reasonable behavior to Zhiheng.
>
> We should definitely simply leave the values untouched when going
> back/forward to a DOM-cached page.
Why? Then .navigation.type may actually lie what was the previous
navigation. 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.
Also, that kind of behavior would actually prevent one
kind of performance timing - BACK_FORWARD + cached DOM.




> Generally speaking the page should
> act as if you never left it. The only difference is that we send it
> events telling it it's going into and out from the cache, as to give
> it a chance to halt things like animations and status updates.
>
> / Jonas
>
>
Received on Tuesday, 22 March 2011 22:48:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC