History back fails to return to original, default view/page in recent Safari (Desktop 5.1.2 + iOS 5.0.1)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load the music sample using a url ending in /music.html
2. Navigate to "Artists" by clicking/touching on the Artists list item
3. Click/touch the browser back button

What is the expected output? What do you see instead?
I expect to return to the main view/page that is titled "Music".  Instead the 
browser stays on the "Artists" page.

Note that if you originally load the page with the _home hash (e.g.  
/music.html#_home) the problem will not occur.

I don't know the exact version of Safari that broke this functionality, but I 
am seeing it on Desktop Safari 5.1.2, but not on Safari 5.0.5.  I am also 
seeing it in iOS 5.0.1 in Mobile Safari.  Any additional information about 
which versions it does and does not work on would be greatly appreciated.

This problem was discovered in iui-0.40-beta1, but occurs in every version of 
iUI back to iui-0.12.

Original issue reported on code.google.com by msgilli...@gmail.com on 9 Jan 2012 at 8:55

[GoogleCodeExporter]

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

• Changed state: Started

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

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