I met with the developer. There are several issues. This will be simplified somewhat due to my limited coding ability (ummm, I had Pascal in High School about 15 years ago - heh).
First, the RoboHelp CSH JS API appears to be broken. We are using IE6, and in the JS API, there is a browser check. First it checks to see if you are using IE4 or greater, and then another check for other browsers. Since this company requires IE for use with their application, the other browser checks are irrelevant to us.
Now, the code for the IE check is intended to identify the browser version, either IE4, IE5, or IE5.5 or greater. Our browser is correctly identified as 5.5 or greater in the RoboHelp JS API. By adding a warning message - some sort of alert syntax, iirc - we were able to determine that for sure, the JS API does indeed recognize the browser as IE5.5 or greater correctly.
After identification, the RoboHelp JS API then makes a call to display the CSH topic.
If you have IE4, due to compatibility I would guess, the RoboHelp JS API calls an iFrame to display the CSH.
If you have IE5 or 5.5 or greater, a JS command called window.open is used instead.
To our surprise, the browser was being identified as IE5.5 or greater, but the iFrame method was being called. This is the method that contaminates browser history. WHY the iFrame does that, I do not know. - one possible solution to the problem would be to find some code that prevents the iFrame call from contaminating browser history. I am not aware if this is possible or not.
This is where the RoboHelp JS API is broken. Where the JS API decides what browser to use, all of the IE specific methods are dependent on identifying the browser as IE4 or better first (vs. some other browser). That's all fine and good, but the logic is set up like this:
First it asks if the browser is IE4 or better, or some other browser altogether. If it is IE4 or better, it sets the IE4 value to True. Since the IE5.5 or greater value is buried beneath this IE4 = True value, the API will never hit any method other than the iFrame method, because in order for IE5.5 or greater to be True, IE4 must be True (which identifies it as an IE vs Some Other Browser), and if IE4 is True, then it uses the iFrame method. Basically this logic is broken.
So we jimmied it - because someone else wrote it so it's time consuming to fix, we rigged the code to jump to the window.open method using a command like && !gbIE5 - which says only use the IE4 method if IE4 is True and IE5 is FALSE. That made it skip the IE4 method and jump down to the IE5 method.
Well, that worked, and our Browser History issue was fixed (because it used the open.window command instead of the iFrame). Unfortunately, there is some sort of additional window opening before the CSH Help window comes up using the open.window method. This additional window is filled with nothing, and does not close after you close the Help window. Thus, it stays onscreen until you close it manually. Here is the code that calls the CSH with the open.window method.
window.open("about:blank", "__webCshStub", sParam);
And a picture of the window properties of this blank window that ruins our "fix" of the API.
Link to Screen of Blank Window Properties
So.... Anyone have any suggestions as to how to do one of three things:
1. Make the iFrame window not contaminate browser history
2. Make the window.open command not open two windows to display a single help CSH call.
3. Call CSH some other way using a JS command that does not cause this kind of issue.
Seems like the API provided with RoboHelp should work a bit better for WebHelp than it does now. Hopefully the new dev team assigned to RoboHelp can fix this.
If you need any more info about this to help me, please let me know.
Please name the file in which you see the code you cite in the most recent message.
You probably will be surprised to learn that the IE4 tag does not revert to false when we graduate to IE5 and greater. In other words, we're carrying around two or more flags, like a grade school and high school diplomas, which makes the "if" logic hard to follow. As a result, IE 5 and 6 go into the IE4 code before the IE5 and 6 routines.
If you don't believe this, put an alarm for IE five immediately after an alarm for IE4. Based on my rummaging through whver.js, and the first launch of WebHelp, you'll get both alarms from IE 5 and 6.
So part of the solution may be this: Screen for IE 4 is true, but IE 5 is not true, to invoke the iframe code. IE 5 and 6 should skip on by and get snagged by the next IE5 screen.
if ((gbIE4) && (!gbE5))
...do the routine for IE 4
IE4 then should skip over the next IE5 filter.
I don't worry about what WebHelp is doing for IE4, of course. But you have to keep IE 5 and 6 out of any activities that are appropriate only for IE 4.
If I'm right, and you see it this way, just imagine what happens to Firefox and Netscape 7.
First every Netscape browser is tagged as Nav4, then if the version is >=5, it's Nav6; later than 2001/07/26 it's Nav61; later than 2002/08/23 , then it's tagged as Nav 7. There's also a Mozilla compatible flag. Firefox is not accounted for, but it picks up all the Nav flags and gets treated as Nav6 or 7.
Please continue to report on your progress, and
Thanks for the response. I think there may be some confusion being caused by the fact that I didn't post which API we're using.
I understand the intended functionality; that the IE 5 and IE 5.5 or greater code is contingent upon IE4 being set to True.
We entered alerts at the first section where it identifies the browser, and were alerted that it correctly identified the browser as >= IE5.5. Of course for gbIE55 to be true, >= 4 and 5 must be too, so gbIE4=true, gbIE5=true and gbIE55 is true too.
But we put in alerts, and the default API appears broken in the section of the JS file under "function ShowWebHelp" where it is supposed to determine which method to use (iFrame or window.open). It always uses the IE4 iFrame method.
See attached code taken from below "function ShowWebHelp". It never puts any contingency on the IE4 true value, and therefore executes the method for IE4 for all versions of IE. It doesn't say "if IE4 is true and not IE5" (that's what we put in to force it to use the open.window method: "if gbIE4 && !gbIE5"), it just says "if IE4 is true, then do this", which results in the IE4 method being used.
It seems sloppy too, because under the "function ShowWebHelp" section where it's executing window calls, there is no reference to IE5.5 or better at all! There isn't one in the server method either. All versions of IE greater than 4 are treated the same. Why identify IE55 as a value and never use it? I'm not a programmer so maybe I'm missing something here, but does this not make sense to anyone else?
In any case, we'd like to use the IE5 method with the window.open call, but our problem is that it is opening two windows and this ruins the experience as much as the browser history contamination. One way they can't go back, and one way they have to close a blank popup window every time they use help. Neither is satisfactory behavior.
I don't have time today but will look at this code to see if I can figure something out.
But you're correct on this point: RH did not age gracefully, and a lot of the X5 enhancements connected with the CSH, as well as browser compatibility ,could use an overhaul. Maybe Adobe has gotten this message.
I'm stll a bit confused about what happenss when you insert t "if gbIE4 && !gbIE5".
Please send me a private email so we can work off-line a bit. If you're in the Continental U.S., and want me to call you, send your phone number.
I'm seeing the same extra blank window in XP with IE6. Even when it's off screen it shows in the task bar.
Did you guys find a work-around for this?
I find the best solution is not not use the CSH API at all. The only benefits to using it is that you can open WebHelp to any combination of mapID, or toolbar displayed.... and since it doesn't seem to work it's pretty useless.
I'm not sure exactly how you want to display your help from the application, but if you want to load it to a specific topic with the navigation frames displayed, you can make a call like this:
<a target=helpwin href=http://www.server.com/robohelp_project/index.htm#topicPath/topic.htm>Help</a>
If you want to make a particular left-nav frame displayed, add in >>cmd=x
where x= 0, nothing; 1,contents; 2, index; 3, search; 4, glossary... so:
<a target=helpwin href=http://www.server.com/robohelp_project/index.htm#glossary.htm>>cmd=4>Glossary</a>
Of course, the CSH API brings some options to the table not available with the above example, such as calling a Map #. You can try using the index_csh.htm file, which is basically a frameset with one frame, cshdat_webhelp.htm, which basically parses everything after the # and relads documents window to the topic using the format of the links above....
using the Map #
<a target=helpwin href=http://www.server.com/robohelp_project/index_csh.htm#TopicNumber=1> Help </a>
Or using the Topic ID:
<a target=helpwin href=http://www.server.com/robohelp_project/index_csh.htm#TopicID=test> Help </a>
Both those will load to a specific mapping, but does not include the navigation frames... to do that, make it:
<a target=helpwin href=http://www.server.com/robohelp_project/index_csh.htm#TopicNumber=1,withnavpane=true> Help </a>
or using the Topic ID too:
<a target=helpwin href=http://www.server.com/robohelp_project/index_csh.htm#TopicID=test,withnavpane=true> Help </a>
Umm... yea that's a bunch of combinations.... As a general rule, the JS files that come with WebHelp are shoddy and undocumented. Best to publish to your webserver and plug away trying to get the desired result.
The only reason I know about index_csh.htm is because I was looking around in the publish directory and stumbled accross it, as well as it's counterpart, cshdat_webhelp.htm.... it took me a while to figure how to get it to work.
I'm afraid that I have to agree with the shoddy and undocumented bit. Funny too that there is a whole different way of encoding the options at index.htm then there is at index_csh.htm: "#<str=MyTopic" vs. #TopicID=MyTopic". The problem with entering lower as you've suggested, is that I need to lose the toobar and location. We want to go as chrome-free as possible.
Do you know a reliable way to get chrome-free CSH via TopicIDs in RH? Or does that spell Flare?
Has anyone found a solution to this problem
No solution, but I can report that it still happens today. I'm using RH 10 to replace a custom help subsystem that actually does manage to handle use of the web browser fwd/back buttons. Our standard is to use RH help though.
It is disappointing to discover that this issue has been present for 6 years and unaddressed. More simplified context from my experience:
We are using this syntax (also noted above):
<a target=helpwin href=http://www.server.com/robohelp_project/index_csh.htm#TopicID=tes t,withnavpane=true> Help </a>
When the user navigates within the help using the TOC, breadcrumbs, or xref links, they can right click in the topic frame and use the web browser fwd/back navigation to move thru the browser history.
If the user then clicks a contextual icon on the app, the browser history is clobbered so these functions no longer work.
Not a showstopper but disappointing.
Try the RoboHelp HTML5 output. That does support the browser forward and back buttons.
I was working on robohelp from a month and do get this issue.
More details on the below thread, help would be appricated: