Grr to IE and its window.location oddities!

I just ran into an odd thing at work recently.

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.

There’s a test page at http://isaacschlueter.com/tests/anchors.html, and I also submitted the bug to PPK.

Hope everyone’s having a happy holiday. Mine was a blast. B)

3 Responses to “Grr to IE and its window.location oddities!”

  1. On January 18th, 2005 at 07:43:36, Schlueterica Said:

    I got published on QuirksModeI submitted that back and forward between named anchors bug to PPK, and he decided to publish it on the QuirksBlog.

    Thanks, Peter!

  2. On March 2nd, 2005 at 21:45:12, StylusEpix Said:

    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.

  3. On March 23rd, 2005 at 18:07:30, Dimitri Glazkov Said:

    Doesn’t work in Opera, either. Actually, it’s worse in Opera — href never includes the hash data.

Leave a Reply

Comments are moderated like crazy using a variety of plugins. There is a very high likelihood that your comment won't show up right away, especially if you have never commented here before, but it was not deleted.

Please be patient, and do not post your comment more than once. It will show up once it is approved.

You must be logged in to post a comment.