Closed GoogleCodeExporter closed 8 years ago
I created a patch on a Git branch that seems to fix it on Safari 5.1.2. I have
not tested it anywhere else, but here it is:
http://code.google.com/p/iui/source/detail?r=d2f3d711b653edd9a9b12d9747fc927aca0
3c865&name=msgilligan-issue-322
Original comment by msgilli...@gmail.com
on 9 Jan 2012 at 9:38
I'm still researching this issue and thought I'd look to see if it was a bug in
Safari. I did find some related bugs:
* Bug 56249: When a hash is set via location.hash then replaced via
history.replaceState, history.back fails to go to the correct state:
https://bugs.webkit.org/show_bug.cgi?id=56249 The referenced demo file
https://gist.github.com/867260 is useful for our purposes and can be modified
to reproduce the Safari issue we are seeing.
* Bug 26812: Hash (anchor) navigation history does not work after
document.location.replace(): https://bugs.webkit.org/show_bug.cgi?id=26812
I'm not sure our issue is a browser bug, because I don't know what the
definitive browser behavior should be.
Original comment by msgilli...@gmail.com
on 16 Jan 2012 at 8:30
Using better Git practices than I did in comment #1, I have a patch that is
just the originalPage fix and created on a branch in a clone repository:
http://code.google.com/r/msgilligan-iui-dev/source/detail?r=6b9da93bc29eb8062952
940d3ceb8a8d9ddf2d6e&name=msgilligan-issue-322b
Remi, et. al., please test this out...
Original comment by msgilli...@gmail.com
on 16 Jan 2012 at 8:39
And here is a test case that shows the possible Safari 5.1.2 bug:
http://msgilligan-iui-dev.googlecode.com/git-history/4d5eda3380b43af508d9e1fd0db
1c739464fe1df/web-app/test/browser-issues/iui-issue-322-safari-hash-bug.html
You can see that Firefox 9.0.1 and Chrome 16.0.912.75 (on OS X 10.6.8) have
different behavior after history.back() than Safari 5.1.2 does. I'm not sure
what the correct behavior is, so I'm not ready to call this a Safari bug.
Can anyone point to a spec and say what the correct behavior should be?
Original comment by msgilli...@gmail.com
on 16 Jan 2012 at 8:50
This looks like it is a or *the* related Safari bug:
https://bugs.webkit.org/show_bug.cgi?id=63777
Original comment by msgilli...@gmail.com
on 17 Jan 2012 at 8:55
OK, so iUI should have been using location.replace() to switch from "" to
"#_home" inside of the onload handler all along.
Here is a patch to do that:
http://code.google.com/r/msgilligan-iui-dev/source/detail?r=6bb62883d0e46d198a28
9a55757a6e205306ca2f&name=msgilligan-issue-322c
This does not fix the issue at hand, but is (I believe) required for correct
behavior.
Original comment by msgilli...@gmail.com
on 17 Jan 2012 at 9:50
And this is the workaround for what I believe is WebKit Bug #63777 (see comment
5, above):
http://code.google.com/r/msgilligan-iui-dev/source/detail?r=bd9efc6e6fc58bba93da
0016fbe5648ce30fecae&name=msgilligan-issue-322c
Please review these changes as I'd like to bring them in to the main repo and
make a release!!
Original comment by msgilli...@gmail.com
on 17 Jan 2012 at 9:53
OK - The fix is now in the master branch of the main repo:
http://code.google.com/p/iui/source/detail?r=ca0a46bff2c4f02fad493526057a30072ee
56403
Original comment by msgilli...@gmail.com
on 23 Jan 2012 at 8:35
Original issue reported on code.google.com by
msgilli...@gmail.com
on 9 Jan 2012 at 8:55