Back button doesn't work after you add a cover

[George]

After I add a new cover, the back button doesn't work. I can still see the history, and choose the previous page using that, but a simple "back" doesn't work.

[George (george-archive)]

(It was a Work cover, for what it's worth.)

[Lance Arthur (lance-arthur)]

I did some investigating and it turns out this is an iFrame-related problem. Loading the iFrame, which loads another page, advances the browser history. When the iFrame is "destroyed" the history isn't altered. There's a write-up here:

http://groups.google.com/group/colorbox/browse_thread/thread/de4da7c98ae6507d

The developer provided a solution for webkit (Safari, Chrome) but it doesn't work in Firefox. The other dev came up with a solution to hide the iFrame in a div and show it when called, but in our solution, due to the number of covers that could be called in, we aren't pre-calling the iFrame sources until the link is clicked.

I think the problem is that using history.length, Webkit starts at 0 while Firefox starts at 1. I'll try to massage the provided script to resolve our problem.

[Lance Arthur (lance-arthur)]

Some further investigation shows that the problem is not related to simply calling the iFrame, the problem only occurs if you take action within the iFrame and end up with the Success screen. In other words, if you just click on the link and open the pop-up and do nothing, and then close the pop-up, browser history is not effected. If you actually select a cover or manage covers and get the Success verification, history advances by 1 and if you attempt to arrow-back in the browser, you need to do so twice.

So... more futzing.

[Lance Arthur (lance-arthur)]

This is either A) unresolvable or B) a problem for Anand.

A) The browser is working correctly. When loading the success page, browser history is altered because a new page was rendered. Using the back button would normally page-back within the iframe first, but the iframe is closed so the history is forced to "catch up" to the window content.

B) Found a solution proposed online: Use an Ajax Post in the form. That won't affect browser history because Ajax calls aren't stored. But I can't code that up, and I'm not sure it'll work in this case.

[Lance Arthur (lance-arthur)]

I cannot proceed further with this bug.

[Anand Chitipothu (anandology)]

Looks like there is a solution to this issue.

http://stackoverflow.com/questions/1597548/form-post-in-iframe-without-affecting-history