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
called.
So the synchronous hashchange causes this problem again;
per the draft the event is dispatched first and the scrolling happens
after that.
-Olli
