Open GoogleCodeExporter opened 8 years ago
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
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
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
[deleted comment]
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
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
Same here
Original comment by marcel60...@gmail.com
on 13 Mar 2008 at 1:55
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
Original issue reported on code.google.com by
bdpathfi...@gmail.com
on 1 Nov 2007 at 10:43