Skip to main content
B
Ben_M-ACS
Participating Frequently
April 6, 2006
Question

Browser History issue

  • April 6, 2006
  • 7 replies
  • 2199 views
I'll be meeting with a developer tomorrow to discuss possible solutions for the Browser history issue, where calling RoboHelp using the CSH JS API creates an entry into the browser history (for IE, at least), and then clicking Back recalls a CSH Help topic instead of taking them to their previous page in the browser.

It appears that I will need to spoon feed them a solution in order to get a fix implemented. I understand scripting enough to muck through HTML, but I will definitely need assistance.

The developer has told me this so far:

"The events that are causing it to be an issue are that the project is sitting out on a file system (rather then web) and second that we are using an IE4 browser, the combination invokes an 'iFrame' instead of a pop-up window and stores a history record in the parents browser history."

This doesn't quite make sense to me, unless the iFrame is the "IE 4 browser", because they've got us all on the same patch and same version of IE 6 at the company. Also, I am deploying this project through a web server, and gave them the URL for it, so we are not using UNC paths to call CSH help, since most of our users will be using the application remotely, and will need to view help the same way.

I can get more details from them tomorrow during our meeting, but if anyone is familiar with the script that calls a "new" browser window instead of one that contaminates the IE browse sequence, I'd love to be able to take that to the meeting right away. Otherwise, I plan on getting the exact code they are using, finding the call that causes the issue, and researching this myself until I am able to send them some scripts back to test until it works. Hopefully I'll have a better understanding of what an iFrame window is after tomorrow's meeting and I can go from there.

This behavior is unacceptable, imo, and I'm going to do whatever I can to prevent my users from seeing it, so any assistance anyone here can provide is greatly appreciated.
This topic has been closed for replies.

7 replies

PY563
PY563
Known Participant
August 31, 2015

I was working on robohelp from a month and do get this issue.

More details on the below thread, help would be appricated:

Re: IE11 renders a blank webhelp popup window(doesn't happen on first instance but from thereon) Version: Robohelp 2015 …

Thanks

A
Anonymous
December 20, 2006
Has anyone found a solution to this problem
F
fashionable_artist157F
Known Participant
September 20, 2012

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.

Willam van Weelden
Willam van Weelden
Inspiring
September 20, 2012

Hi,

Try the RoboHelp HTML5 output. That does support the browser forward and back buttons.

Greet,

Willam

T
ToddBlume
Participant
September 13, 2006
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?

-Todd
H
HKabaker
Inspiring
April 14, 2006
Ben,

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.

Harvey
H
HKabaker
Inspiring
April 13, 2006
Ben,

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.


Harvey.
H
HKabaker
Inspiring
April 10, 2006
Ben,

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.

something like:
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

Good luck.

Harvey
B
Ben_M-ACSAuthor
Participating Frequently
April 11, 2006
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.

It's the default Javascript API from the CSH API folder. The file name is RoboHelp_CSH.js. I looked at the whver.js file, and it appears to ONLY identify the browsers. I see what you mean about carrying flags, and we observed the behavior, but found a glitch.

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.
B
Ben_M-ACSAuthor
Participating Frequently
April 10, 2006
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.

if (gbIE5)

window.open("about:blank", "__webCshStub", sParam);

window.open(a_pszHelpFile, "__webCshStub");

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.
T
tswaters1
Inspiring
September 13, 2006
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:

Topic Number:
<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>

Adding in ",withnavpane=true" seems silly, i know, but it's hardcoded into javascript code in "cshdat_webhelp.htm" and works.

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.
T
ToddBlume
Participant
September 14, 2006
Thanks,

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.

I'm calling into the WebHelp from a C# application - not a web page. Apparently that makes some things, like closing the temp windows, problematic. And as far as I can tell, customizing the browser appearance has to be done inside JavaScript if you want to be browser independent. So I'm kind of stuck with index.htm unless there is another way.

Do you know a reliable way to get chrome-free CSH via TopicIDs in RH? Or does that spell Flare?

Aloha,
Todd
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices