Okay, Ryme: it happened again, so I sent 4 accounts through their paces, and the problem is at least a little more defined. See if this helps out any. (And maybe someone else can fill in the bits that I just don't get.)
SUMMARYIt's not just in the header, and the problem isn't really the links themselves (which we figured). Among other things, Firefox appears to be “acking” on the following code
Code:
<script type='text/javascript'>if (self.location == top.location)
top.location.href = 'index2.php';</script>
which appears in some TH pages. (My reasoning is spelled out below.) FF also seems to be choking up on frames for some reason, but I haven't figured out how or why. And I'm convinced that it only does this when it gets upset about something else entirely (but I don't know how to prove it).
(BTW, Shoudn't that code be
Code:
window.top.location
?)
Whenever this error happens, I always see an error in FF's Error Console that may be a cause or may be a symptom:
Code:
Error: Warning: unrecognized command line flag -psn_0_84279297
Source File: file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js
Line: 706 if (curarg.match(/^-/)) {
I've no clue what that means, and it would take me hours to sift through the file and figure that out; I'm a rookie when it comes to javascript.
(MOST OF) THE GORY DETAILS
Symptoms from User EndScopeOn the opening page after login, the navigation from select links in frames “header,” “nav,” and “footer” was affected. All frame “chat” links worked properly. The image map in frame “main” was not tested because it had appeared to work in the past.
What workedAll links that target new windows worked properly. As mentioned, all links that target frame “chat” worked properly, and the pop-up chat definition worked properly. The “Last Area Patrolled” link in frame “nav” worked properly, opening the last patrolled area inside frame “main”-- even though “Last Patrolled” was different for each of the four accounts. Logout links worked properly. After adventuring the “Last Patrolled” area, the “Main” links in frames “header” and “footer” each worked properly.
What didn'tLinks to files in the folder “maps” opened full screen (no frames). “Bugreport.php” also opened full screen. All links not yet mentioned--various links from frame “header,” plus the character link in frame “nav”--seemed to route the user directly back to “main.php.”
All errors were duplicated in all four accounts. Chat links were no longer tested after the second account. Testing on links that target new windows stopped halfway through the third account.
The Reality from the Dev SideThe links that appeared to route to “main.php” did in fact visit their respective pages before re-routing. In all 4 accounts, clicking on sounos's Greasemonkey “Rest” link in the header caused the character to gain HP and PP and lose minutes, but the user was still routed back to “main.php.” (This link normally takes the user to "rest.php." See
http://twilightheroes.com/forums/viewtopic.php?t=148 for the script.) Careful observation (and a sporadically slow internet connection) revealed that all links were attempting to call their respective pages before being re-routed back to "main.php."
All pages that re-routed back to “main.php” contain the javascript noted above. None of the files from folder “maps” have this script, nor does “bugreport.php.” (These are the files that broke out of frames in order to work.)
“Fight.php” does contain this script, however, and links from frame “nav” to the combat area worked. Could this be due to a difference in quotation marks in the target attribute? FF hanging up on something else in the code that I just didn't see? Who knows?
Final SuggestionTry tinkering with the javascript named in the summary and see if your bug reports go down. If so, do you start getting errors about the site breaking out of frames?
I wish I could be of more help, but maybe that'll narrow things down a little!
Edited twice for clarity, 11/25/07.-- Doc Whatsit.