[whatwg] nested hashchange events
Olli.Pettay at helsinki.fi
Tue Sep 8 14:08:18 PDT 2009
On 6/25/09 11:44 AM, Olli Pettay wrote:
> Hi all,
> currently "6.11.9 History traversal" doesn't seem to handle
> nested hashchange events too well.
> If there is a fragment id change to A, hashchange is dispatched, then
> if the listener changes the fragment to B, there is a new hashchange and
> after that the page will scroll to B. But the fragment change to A
> hasn't finished yet, so the page will then scroll to A.
> Either one should be able prevent the default action of hashchange
> (scrolling), or hashchange should be dispatched after scrolling.
> I think I'd prefer the latter. That would keep things simple and prevent
> all sort of strange cases like the example above if preventDefault isn't
So the synchronous hashchange causes this problem again;
per the draft the event is dispatched first and the scrolling happens
More information about the whatwg