[Javascript] Back and forward between named anchors doesn't update window.location

[frank at bradet.com]

Quoting Quirksmode @
http://www.quirksmode.org/bugreports/archives/2005/01/Back_and_Forward_between_Named_Anchors_do_not_upda.html

Test page by Isaac Z. Schlueter:
http://www.isaacschlueter.com/tests/anchors.html

"""When navigating between named anchors in IE, the window.location object
changes to reflect the change in the URL. This is correct. However, the
window.location object should also change when you use the back or forward
buttons, or the history.back() and history.forward() methods, to move
between these anchors, and in IE 6.0 and IE 6.1, it does not."""


I've noticed this bug as well, and I believe that it is an intentional
security measure, so that the browser 'back' button can less easily be
highjacked. However, the ability to observe window.location changes is a
critical requirement for AJAX applications that want to offer a consistent
user interface.

On navigators that do indicate changes in window.location when navigating
between named anchors, javascript can, through a polling timer, provide
proper back and forward button support *without reloading the current
page*.

Consider a javascript-enabled navigational menu. Each menu item is a link
to an internal anchor, and an onclick event triggers the loading of inner
page content through the use of XMLHttpRequest. This provides a highly
responsive user interface, which is normally not associated with HTML.
Rather, web users expect full page reloads on each click. Not only does
this consume bandwith, but also CPU power to re-render each page
completely. A better way is this AJAX navigational interface.

Now, this navigational interface works quite well on most browsers, but
one element is critical to make it fully consistent with a user's
expectations of the Web platform: support for the Back and Forward
buttons, as well as Reload, Bookmark, and a change in displayed URL
between page views. That element is a way to detect user-triggered actions
such as Back and Forward that modify the window.location. On Mozilla-based
navigators, a setInterval timer detects such changes and uses
XMLHttpRequest to show the user the appropriate content. A 100ms poll
latency is gentle on system ressources and very responsive.

I have successfully implemented such a navigational interface which
provides the user with the proper and expected experience. My
implementation uses completely optional Javascript, which if not available
on the user's browser, leaves him with a fully functional (albeit slower)
XHTML+CSS interface. On Mozilla-based browsers, it works very well.
Through use of an adaptive preloader, the responsiveness is brought to an
even higher level.

However, this revolutionary interface is impractical for a very simple and
frustrating reason: IE does not support monitoring window.location
changes, thus making the interface inconsistent for 90% of web users.

This is why a solution must be found. I have identified possible avenues
through which this IE 'feature' may be bypassed.

1. Monitoring of window.history.length, which increments by one when the
user clicks on Back. This would have to be combined with some sort of
additional page load, which would bring the user forward without doing a
page reload. A full navigation history within the current page would need
to be kept. Backwards history leaps longer than one item would not work.
The Forward button would not work. But it may restore expected Back button
behaviour. It would also require use of a polling monitor triggered by
unexpected window.history.length incrementation.

2. Perhaps VBScript does not suffer from this unfortunate limitation. It
could provide the window.location change monitoring services, relaying
those changes to the Javascript.

3. While it is doubtful that it does, Flash may have access to this
information. However, Flash is usually quite limited by its sandbox. If
not, it could work in cooperation with Javascript, such as is described in
2.

4. Creative use of hidden frames, forward-redirects and
window.location.current overrides may also provide a solution. This would
likely require server-side cooperation.

5. Creative use of a redirect page located just before the content page,
as well as server-side session navigation history and state, perhaps in
combination with techniques mentionned in 4.

This IE 'bug' or 'feature', call it what you will, prevents AJAX
applications from being the new revolution on the Web. A solution must be
found, no matter how unelegant; as long as it is transparent to the user.
If you have any ideas, please contribute them.

Thanks.