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

[whatwg] Onpopstate is Flawed

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 31 Jan 2011 18:32:33 -0800
Message-ID: <AANLkTi=Ypmq8Q+igL=Dx1kCgXACBJVP=zu5on0=j=AZ7@mail.gmail.com>
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
Received on Monday, 31 January 2011 18:32:33 UTC

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