If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

help with safari bug (not an easy one)

I apologize up-front for this being so long of a post, but because there's so much going on in my code, I need to do some heavy explaining before getting to the issue.

Yesterday I launched the new website for our church at www.trinityumcarlington.org. I designed the site using mootools and some generic javascript. It seems to work fine in IE and FF, but in Safari (at least on mac) the back button causes some major issues. Because of the way the site is set up, the back button functions as follows:

Whenever a user clicks on a menu option, they do not leave the index.html page. Instead, menu options use Mootools to move images in/out of the screen, simulating the effect of different 'pages'. When the user drills down to the lowest level in a menu option, an iframe is created and a basic html page loaded in it to show the desired text. Since browser history takes into account iframe histories, when the user clicks on another menu option the iframe is disposed of, thereby clearing it's history. This creates the effect of the history always showing 'index.html'. The code I'm using to create/dispose of the iframes is:

The variable 'subTxt' is set to the dependent html to be loaded in the iframe, based on which menu option is selected by the user.

Now, to give the browser a functional history to be used with the back button (so that clicking the back button doesn't just take the user back to whatever site they were coming from), I created a small (0x0 to be specific) iframe hidden from view that loads a separate page for each menu option available. The code in one of these html pages looks like:
/historyLoader/adults.html:

Meanwhile, the function 'BackCheck' that it calls from the parent document contains the following:

Code:

function BackCheck(e){
if (varX == "false"){}
else if (varX == "true"){
if (e=="whoweare"){WhoWeAre()}
if (e=="ministries"){miniStries()}
if (e=="spirit"){SpiritDisc()}
if (e=="involved"){GetInvolved()}
if (e=="media"){mediaLayout()}
if (e=="resources"){ResourCes()}
if (e=="home"){homeB()}
if (e=="p2k"){p2k()}
if (e=="adults"){adUltsMinistry()}
if (e=="child"){childMinstries()}
if (e=="music"){musicMinistries()}
if (e=="community"){communityLayout()}
if (e=="local"){localOutreach()}
if (e=="congregational"){congregationLayout()}
if (e=="financial"){financialLayout()}
if (e=="worship"){worshipLayout()}
}
}

(the variable varX is used on each menu option function by first setting it to 'false', and then running the function, which, among other things, loads the above adults.html file into the hidden iframe, and then sets the varX to 'true' on a delayed call at the end of the function. Thus, when the adults.html (or whichever) is loaded from the menu option function, it sees that that varX is false and does nothing. However, when the user presses the back button, the browser reads the history of the iframe, loads the appropriate html file, which checks and sees that varX is true, and then runs called function - in this case, adUltsMinistry(), as if the user had clicked that menu option.)

Hopefully that all made sense!

As I said, this seems to work fine in IE and FF. And it even works in Safari, so long as the user hasn't loaded one of the lowest-level options, thereby creating/disposing the iframe in the 'parentDiv' element. Once that happens, if the user clicks 'back' in Safari, it reloads the entire page, as if 'index.html' was just loaded in the history. I've noticed this happens one of two ways:
1) the user navigates to menu option 1, then to menu option 2 (where 2 is the lowest level with created iframe), and tries to go back to menu option 1. Upon doing so, the index.html page is reloaded.
2) the user navigates to menu option 1, then to menu option 2, then to menu option 3 (which is not a lowest-level option), and then tries to go back to option 2. Same result.

However, if the user goes to menu option 1 then menu option 3 (neither are lowest-level), then goes back to 1, it behaves as intended. Also, if the user goes from 1 to 2 to 3 to 4 (where 4 is also a non-lowest level option), and then goes back to 3, it works fine. Of course, if they hit back again and reload option 2, it reloads index.html.

You probably just need to load the page and see it for yourself.

I'm really at a loss for what's going on in Safari. Any help would be greatly appreciated!

It still eliminates the iframe from creating an undesired history record as every time the iframe is loaded with content, it is completely created anew using the innerHtml code. But for some reason when the innerHTML for the parentDiv was set to ' ', it caused Safari to not know what to do.