CSH--Doesn't fire in Firefox

Report · Feb 23, 2007

When I click the Help link in one of our applications in Firefox, the help doesn't fire. On mouseover, the status bar shows "javascript:;" (due to our header being in an include file, so we're calling the help using onClick:displayHelp() and then running the CSH help call string within a JavaScript function called displayHelp). When I click, I don't get a JavaScript error or anything--nothing happens at all.

The CSH launches fine in IE6 and 7, which is fine because we use IE in-house, and that's where this system is used. However, we're getting the help started for another application under development, which will be used in various places around the world. That system has to use the same JavaScript methods as the first system, and again it doesn't work in Firefox. We may have users using Firefox, and we don't want to tell them that Firefox doesn't support the help system. I'm stumped. Any help for the helpless...? According to community experts in other posts, conflicts between CSH and Firefox aren't common, or at least aren't commonly reported.

Details: FlashHelp output, Firefox 1.5.0.9, JavaScript enabled, all checkboxes checked in advanced JavaScript options. Same behavior whether pop-up blocker is on or off. In a third application, FlashHelp launches fine in Firefox, but that system doesn't use CSH.

Thanks in advance!

Report · Feb 23, 2007

Ben,

Firefox has been updated to V 2.x. Every new version brings improvements.

Harvey

Report · Feb 25, 2007

Hi. If I understand, you are not using the RoboHelp_CSH.JS (the WebHelp API) that comes with RoboHelp, is that right?

Here is a website using the WebHelp API that I've tested in Firefox 1.5.0.9 as well as the newer v 2 and it seems to work fine.
www.johndaigle.com/bdb

The WebHelp API is nothing more than a JavaScript include file with a list of JS functions that can be called from any HTML page. You'll find it in RoboHelp's installed path (something like: Program Files\RoboHelp Office\RoboHTML\CSH API etc.)

Other than that, I'm afraid I'm not a developer and not familiar enough with your code to suggest alternatives. If you don't to use the WebHelp API, perhaps by looking at what RoboHelp offers, you could diagnose and modify your code to make it work. You might also check out my article on the Adobe RoboHelp Developer Center
Providing Context-Sensitive Help for Web Applications

You may also want to look at Peter Grainge's resources at this URL
Calling WebHelp

Hope this helps.
John Daigle
Adobe Certified RoboHelp/Captivate Instructor

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Newport, Oregon

Report · Feb 26, 2007

Thanks for the replies.

Harvey, no difference in Firefox 2.

John, I am using RoboHelp_CSH.js--as far as I can tell, I'm implementing this the way it's described in RoboHelp's help, with the exception of putting the RH_ShowHelp function within the displayHelp function. Your post reminded me that when I upgraded to 6.0, I didn't replace the X5 JS with the 6.0 JS (not having compared them to see if there are any differences). After having done so, however, I'm still not getting anything in Firefox. The links you provided didn't seem to give information beyond what RoboHelp's help gives.

In case this will help (why Firefox would have a problem with this, I don't know), this is how the displayHelp function is coded--

In the header include file, we have:

<a href="javascript:;" onClick="displayHelp()" class="buttonwhite">Help</a>

In each page, we have the function call in <script> tags, like so:

function displayHelp(){
RH_ShowHelp(0, "***.htm>FlashWindow", HH_HELP_CONTEXT, 6);

Everything seems to be intact (RoboHelp_CSH.js is in the right place and is linked to in our pages' <head> tags, etc.), seeing as how it works in IE.

Our interaction designer is reviewing the JS code to see if there is anything he can find that Firefox could be choking on, but I appreciate any other input here. Thanks!

--Ben

Report · Jul 09, 2007

I don't have an answer - only the same question. We have context sensitive webhelp & when using Firefox, the topic flashes up briefly then goes back to the "parent" topic. We're also wondering if we are going to have to tell our customers that we recommend IE only.

Report · Jul 09, 2007

Ben and Cindy,

Try this patch, in the output file whtbar.js, near the end:

function tryReload()
{
if (gnRE==1)
// document.location.reload();
gnRE--;
}

Insert the // to comment out the middle line.

Here's a better display.

Report · Sep 12, 2007

Hi Cindy,

I found a solution that works for me using the "skinless" webhelp, and I believe should work with Flashhelp too: in the whtopic.js file, comment out the last line:

document.location.reload();
becomes:

//document.location.reload();

Tested in Firefox 2.0 and IE 7. Seems to work. Over to QA for me!

Report · Jul 09, 2007

I don't have whtbar.js in my output. FlashHelp probably doesn't generate this file (though I imagine it's WebHelp that does). I did a text search for "gnRE" and "tryReload" in my output directory, with no results. Searching for "document.location.reload" turned up a few places that don't look like the code you posted. Do you know of comparable code in FlashHelp's output?

Report · Jul 09, 2007

Oops, sorry. I thought we were talking about WebHelp.

H

Report · Jul 10, 2007

Well, HKabaker, I was talking about Webhelp so you helped me! I put the // in but we haven't been able to test it yet. We have to wait for Ops to copy the files over. When that happens, I'll let you know if it helped! Thanks!

Report · Jul 17, 2007

Well, we ended up NOT using this suggestion. I read somewhere else in this forum to try unlinking the TOC books. We did that & it fixed the problem of the context sensitive help not working correctly in Firefox.

Thanks!

Report · Aug 10, 2007

commenting out document.location.reload(); did not help me neither. Are there other suggestions? Tried out a lot already :-)

Report · Aug 10, 2007

URLs instead?

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Report · Aug 10, 2007

Hey Peter,
I do not know how you mean urls... sorry!
I tried cindys solution of unlinking the topics but it does not work... I call the help as follows. Perhaps, thats the prob?

Report · Aug 10, 2007

A link as below would open a topic with Show at the top to enable the user to access the navigation pane.

<p><a href="path/topic.htm">Link Name</a></p>

This link would open the help at the required page but with the TOC and toolbar displayed.

<p><a href="path/startpage.htm/path/topic.htm">Link Name</a></p>

There's a topic about calling webhelp using URLs on my site.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Report · Aug 10, 2007

Hey Peter, thanks for your effort!!!
The prob is that the developer wants to call the help using an id with the datatype string (in my example 'TaskList').
That would mean that I have to implement myself the mapping between the id:string from the calling application over the RoboHelp mappingID:int to the url:url - which means ignoring index_csh.htm as a whole... and all that just because of a FireFox-Bug?
By the way: Is there somewhere documentation available for WebHelp? It is really a pain to fix bugs or enhance functionality without documentation, just some comments and cryptic variable names...

Report · Aug 10, 2007

I guessed that might be the case. The suggestion was made in case both you and the developers were ready to resort to a new method.

Documentation for webhelp. The workarounds are covered in these forums and sites such as mine or RoboWizard's at www.robowizard.com. There are some books around (see Links on my site) and various courses but I don't think that is what you are looking for.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Report · Aug 10, 2007

Hey Peter; thanks again! Actually I'd love to be able to take strings as ids... Anyways, with testing against browser history I am able to limit the problem a bit (see following code snippet, whthost.js, around line 200).
The limited documentation is definetively a problem... but lets share insights and create our own documentation 🙂

Report · Aug 10, 2007

Peter, some questions about using URLs:

Do you know if calling help using URLs instead of map IDs works in Firefox specifically? Does calling with URLs support the ability to specify window attributes in FlashHelp (.../***.htm>FlashWindow)? If you use URLs, do you still need RoboHelp_CSH.js?

If we switch to URLs, the developers will have to go back through and recode the help call on each page. But there is no point discussing it with them if Firefox will choke on the URL method also.

Report · Aug 10, 2007

The method works but see the Browsers topic on my site. No you cannot specify the window attributes and no you will not use the CSH file. It is just a straight URL.

Yes the developers would have a lot of work so it is a method you will only use if the pros and cons weigh in its favour.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Report · Sep 12, 2007

Thanks, Jeff.

This line of code is not at the end of whtopic.js for FlashHelp, but it is there about 3/4 of the way down. I commented out just this line, and it my FlashHelp now comes up in Firefox if the pop-up blocker is turned off or pop-ups are allowed for the site. If pop-ups are blocked, Firefox gives the option to allow them, so I hope a user viewing in Firefox would take note that the site needs pop-ups for the help to work in that browser.

Also appears that IE6 doesn't have any problems with this line being commented out, which is important because that is mainly what our customers are using.

Case closed.

--Ben

Adobe Community

CSH--Doesn't fire in Firefox

1 Correct answer