- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 23 Mar 2011 00:47:36 +0200
- 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