IE6/7: When users type their own hashes in the address bar, history behaves erratically

[GoogleCodeExporter]

O.6 Beta: History behaves erratically when user manually types in a new
hash in the address bar. The code to handle this gracefully appears to have
degraded.

The comments in the code that handles this in 0.4 contradict the actual
logic, so maybe this was broken all along? Needs more investigation. See
the TODO note in the source code.

Original issue reported on code.google.com by bdpathfi...@gmail.com on 1 Nov 2007 at 10:43

[GoogleCodeExporter]

Upon further investigation, these cases were always problemmatic. Testing in 
IE6 with
RSH0.4, I see the same behavior as I do with RSH0.6. If the user manually makes
changes to the hash in the address bar, fireHistoryEvent gets fired 2x (once by
iframeloaded and once by the actual listener). Thereafter, things get 
super-wonky.
From there on out, all history entries from your entire session get wiped. You 
can
add additional history points within the app, but they don't get added to the
browser's history (you can't see them when you click hold down the back 
button). From
here on out, the minute you hit the back button, you get sent back to the page 
you
were on BEFORE hitting the RSH. Documentation, etc. all seem to indicate that 
this
once worked, but I can't see that it did. Perhaps IE6 patches since the original
release of RSH0.4 broke this? I'm hoping Brad might have time to comment.

Original comment by armchai...@gmail.com on 8 Nov 2007 at 6:17

[GoogleCodeExporter]

I think this did used to work; however, Windows updates and IE 7 have caused it 
do
degrade. I think some iterations of IE 6 (they all report the same version 
string but
in fact differ between manufacturers and various COM components changed by 
Windows
update patches) might also have not worked. So my version of IE worked and some 
of
the machines I tested worked, but other versions of IE 6 wouldn't work. 

I wonder exactly what the browser is doing when you manually change the URL.... 
might
be useful to simplify this to a test-case and experiment with things -- thats 
how I
figured out most of the mechanisms behind RSH. 

Original comment by bradneub...@gmail.com on 9 Nov 2007 at 6:38

[GoogleCodeExporter]

Is there any update on this issue? Similar issues known on other history
implementations? I am currently doing a project using Backbase (4.1), and have 
the
exact same problem.

Original comment by marcel60...@gmail.com on 11 Mar 2008 at 10:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What is noticed is that when you change the hash, the print button is disabled 
and
the IE developer toolbar shows no document, as if IE has lost the entire 
document.
The document seems still accessible through js though...

Original comment by marcel60...@gmail.com on 11 Mar 2008 at 11:09

[GoogleCodeExporter]

I could only reproduce this on IE6, on IE7 the manual inclusion of the hash on 
history works fine.

Original comment by wesley...@gmail.com on 12 Mar 2008 at 1:16

[GoogleCodeExporter]

Same here

Original comment by marcel60...@gmail.com on 13 Mar 2008 at 1:55

[GoogleCodeExporter]

I implemented a workaround, where i can detect the history getting corrupt. If 
so, i
reload the page. For me this is a acceptable workaround because my Ajax app has 
full
state persistency.

My workaround does the following:

1. When the app starts set a global that remembers the initial history length 
of the
browser (__initialHistoryLength = history.length)
2. Create a counter that keeps track of the number of times you tried to set *a*
bookmark within the App.
3. Right before you set a bookmark other than the one that is already in the 
hash,
you increment the counter by one.
4. Set the bookmark.
5. In case the counter is bigger than two*, and either the initial length is 
the same
as the current history.length, or history.length equals 0, we
document.location.reload() the page.

Of course all except step 4 is wrapped in if(ie6) statements.

* IE somehow does not set the has the first time, which might be a Backbase 
history
specific bug.

Original comment by marcel60...@gmail.com on 13 Mar 2008 at 2:05