Re: [NavigationTiming] few comments

On Tue, Mar 22, 2011 at 6:35 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Mar 22, 2011 at 3:47 PM, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:
> > 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.
>
> It's not a lie. It's just contains the values that were relevant when
> the page was loaded.
>
> Put it this way instead. What is the value of getting some new set of
> performance values for the "navigation" to the bfcached page.
> Absolutely no network activity takes place when navigating to the
> bfcached page and so it seems to me that there is no interesting data
> to expose.
>
> The only result that I can see is that pages will now have to be aware
> that at any point the values in .navigation can suddenly be cleared if
> the user navigates away from the page and then back. So pages will
> *have to* register for pagehide/pageview events if they want to be
> sure of consistency in the data. This is different from how things
> work now when pagehide/pageview are there solely for optimizations.
>

   +1 to this.

  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?

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
>