W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] pushState and session history issues

From: Mihai Parparita <mihaip@chromium.org>
Date: Thu, 12 Aug 2010 17:19:48 -0700
Message-ID: <AANLkTinkaKknn8wnfq0rkgxW0H4X5TFyH5NkbCa-ENRF@mail.gmail.com>
On Thu, Aug 12, 2010 at 4:56 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 27 Jul 2010, Mihai Parparita wrote:
> > https://webkit.org/b/42861 has more tests, but briefly, the behavior
> > in the latest stable versions of these browser is:
> > - Firefox will not create a session history entry if the navigation is
> > executed inline, or during an onload handler
> > - Chrome will not create a session history entry if the navigation is
> > executed inline, or within 5 seconds of the onload handler firing
> > - Safari will always create a session history entry
> > - IE will not create a session history entry for hash changes during onload only
> >
> > My proposed change to WebKit is to not create a session history entry
> > for location changes that happen before onload fires if they are not in
> > response to a user gesture. I would also be modifying Chrome to remove
> > its custom logic for this and just inherit WebKit's.
> >
> > Does anyone see any compatibility problems with this? Should the HTML5
> > history section mention anything about navigations caused script vs.
> > user gestures*? I realize that replace() should obviate the need for
> > such a heuristic, but given that 1) other browsers seem to do this and
> > 2) sites like hp.com don't get it right, there may be a need for it.
> >
> > * It only alludes to something similar: "In addition, a user agent could
> > ignore calls to pushState() that are invoked on a timer, or from event
> > listeners that are not triggered in response to a clear user action, or
> > that are invoked in rapid succession."
>
> IE's behaviour seems the narrowest; would it be acceptable? Failing that,
> how about any navigations until the end of the load event task?
>
> The proposal here would be to just assume a scripted navigation is done
> with replacement enabled in the condition described above, right?

Based on the way the discussion has evolved in
https://webkit.org/b/42861, the consensus is that your second option
("any navigations until the end of the load event task") is preferable
(given that sites already do this, e.g. the Wikipedia mobile
"redirect"). ?Would form submits also be counted as navigation?

And yes, this woud be just be navigation with replacement enabled.

Mihai
Received on Thursday, 12 August 2010 17:19:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC