This content has been marked as final. Show 20 replies
Firefox has been updated to V 2.x. Every new version brings improvements.
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 18.104.22.168 as well as the newer v 2 and it seems to work fine.
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
Hope this helps.
Adobe Certified RoboHelp/Captivate Instructor
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:
In each page, we have the function call in <script> tags, like so:
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!
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.
Ben and Cindy,
Try this patch, in the output file whtbar.js, near the end:
Insert the // to comment out the middle line.
Here's a better display.
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?
Oops, sorry. I thought we were talking about WebHelp.
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!
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.
commenting out document.location.reload(); did not help me neither. Are there other suggestions? Tried out a lot already :-)
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?
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.
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...
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.
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 :-)
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.
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.
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:
Tested in Firefox 2.0 and IE 7. Seems to work. Over to QA for me!
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.