W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Onpopstate is Flawed

From: Henry Chan <henry.fai.hang.chan@gmail.com>
Date: Wed, 2 Feb 2011 00:19:25 +0800
Message-ID: <AANLkTimx=ByeX-DhQV7Zmdr+b0mwbw8widG0=f1d97Ph@mail.gmail.com>
Thanks, you save my life!!

Btw i'd reli like the onpopstate to fire as early as possible, possibly
before images are requested/dom is fully loaded.  But this is already great
enough :D


On Tue, Feb 1, 2011 at 10:32 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Thu, Dec 23, 2010 at 6:18 PM, Henry Chan
> <henry.fai.hang.chan at gmail.com> wrote:
> > It fixes the bit where back/forward before onload doesn't fire
> onpopstate.
> > But no, it still doesn't let us detect inital onpopstate.  And
> back/forward
> > buttons don't work properly until onload.  A workaround would be to
> assign
> > the handlers to the <a> tags at onload but again that's not feasible for
> my
> > site.  I need it domready.
> > Please make onpopstate fire as early as possible in the navigation
> sequence.
> >  And drop the pending state object.  I need exactly each firing.  Not
> just
> > the last one.
>
> Would the following behavior solve your issue:
>
> If pushState or replaceState is called before the initial popstate,
> simply don't fire the after-onload-popstate.
>
> If the back button is pressed (or history.back() is called) after a
> pushState/replaceState, but before onload, fire a popstate for the
> newly transitioned to state. Still leave the after-onload-popstate
> canceled.
>
> I.e. if the webpage calls pushState or replaceState before onload
> fires, then it is deemed that the page has transitioned to the new
> state and no after-onload-popstate is needed.
>
> This behavior makes the most sense to me and allows the page to start
> handling state transitions before the page finishes loading.
>
> / Jonas
>



-- 
Henry Chan
henry.fai.hang.chan at gmail.com
Administrator of www.123got-it.com
Received on Tuesday, 1 February 2011 08:19:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC