Comments on: Grr to IE and its window.location oddities! http://isaacschlueter.com/2004/12/ie_window_location/ Just slightly more than my twitter stream. Fri, 20 Nov 2015 19:11:47 +0000 http://wordpress.org/?v=2.5.1 By: Schlueterica http://isaacschlueter.com/2004/12/ie_window_location/#comment-19 Schlueterica Tue, 30 Nov 1999 00:00:00 +0000 #comment-19 <strong>I got published on QuirksMode</strong>I submitted that back and forward between named anchors bug to PPK, and he decided to publish it on the QuirksBlog. Thanks, Peter! 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!

]]>
By: Dimitri Glazkov http://isaacschlueter.com/2004/12/ie_window_location/#comment-20 Dimitri Glazkov Tue, 30 Nov 1999 00:00:00 +0000 #comment-20 Doesn't work in Opera, either. Actually, it's worse in Opera -- href never includes the hash data. Doesn’t work in Opera, either. Actually, it’s worse in Opera — href never includes the hash data.

]]>
By: StylusEpix http://isaacschlueter.com/2004/12/ie_window_location/#comment-21 StylusEpix Tue, 30 Nov 1999 00:00:00 +0000 #comment-21 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. 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.

]]>

Warning: fopen(/var/www/isaacschlueter.com/public/wp-content/cache/meta/wp-cache-256c1f3c85d48cc0552e4dc122ae7ec0.meta) [function.fopen]: failed to open stream: Permission denied in /var/www/isaacschlueter.com/public/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 378

Warning: fputs(): supplied argument is not a valid stream resource in /var/www/isaacschlueter.com/public/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 379

Warning: fclose(): supplied argument is not a valid stream resource in /var/www/isaacschlueter.com/public/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 380