[whatwg] Onpopstate is Flawed

Justin Lebar justin.lebar at gmail.com
Wed Feb 2 14:05:55 PST 2011

I'm a bit uncomfortable with this behavior, since it seems that having
replaceState cancel the initial popstate is at least somewhat

How is this better than never firing an initial popstate?


On Mon, Jan 31, 2011 at 6:32 PM, 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

More information about the whatwg mailing list