Copy link to clipboard
Copied
Our web portal uses map IDs to open context-sensitive help topics. After being upgraded to Firefox version 41.0.1, I noticed the help links in the web portal no longer open the appropriate help topic. Instead, the links now open the default topic.
I tested the same help links in our web portal using Google Chrome and a few different versions of Internet Explorer, and the links open the correct help topic in those browsers.
Has anyone encountered this problem with Firefox? I'm using RoboHelp 2015 and outputting to WebHelp.
Copy link to clipboard
Copied
I’ve never been able to get any other browser by IE to be launched when my CSH WebHelp is called from our app; but I was concerned that FF had tightened up their security again, so I just updated to 41.0.1 and tested that the full help still works – and it does (phew).
Copy link to clipboard
Copied
We are experiencing the same issue after being upgraded to Firefox 41.0.1. Our web portal also uses map ids to open the context-sensitive help. It no longer opens the appropriate topic and instead opens the default topic. I have tried other browsers, such as Chrome and Internet Explorer and they work fine.
Any resolution to this issue?
Copy link to clipboard
Copied
We have the same problem.
Firefox 39 is ok, Firefox 41 not.
We are working with RH 11 and Map IDs.
When you try to open the online help contex sensitive the start page opens, not the linked page.
Most of our users working with FF. So a solution is very important for us. Who can help???
Copy link to clipboard
Copied
Hi,
Good news coming..
We have released the fix at Context-sensitive WebHelp topic calls not working in Firefox
Give it a try and let us know.
Edit: Fix is applicable for both RoboHelp 2015 and RoboHelp 11.
Thanks and Regards,
Surbhi Maheshwari
Copy link to clipboard
Copied
I've loaded your fix and have done some initial testing..so far, everything looks great! I will continue to test and let you know if I run into any other problems. Thank you for your help!
Copy link to clipboard
Copied
The fix works nearly good for us.
There is one open issue concerning another fix (self-made) for Edge display problems.
(see RoboHelp 10: WebHelp Blank Page in Microsoft Edge and Re: Does your WebHelp work well in Microsoft Edge?)
When I run a context sensitive Webhelp including the FF fix, the Toc area is empty in Edge .
Without the fix (only with the edge fix) Toc is visible...
So, it would be great, if there would be a fix including both problems.
Copy link to clipboard
Copied
I implemented the fix, but it didn't resolve my problem. In fact, the fix introduced new issues in Internet Explorer and Chrome. I'm suspicious about how our web portal calls help topics. Am I making a relatively safe assumption that this fix would more likely work if our web portal were using the CSH API (in our case, JavaScript) than if our web portal were using some home-grown method to call help topics?
Copy link to clipboard
Copied
Hi,
What issues are you facing in IE and Chrome?
Even if you are using your custom API to call CSH Help, it should work after applying the fix.
But if this fix is breaking your IE and chrome workflow also, can you please share your custom API and the way you are calling the help?
Regards,
Surbhi Maheshwari
Copy link to clipboard
Copied
We have two different types of topics: page-level and field-level.
The issues I see in Internet Explorer and Google Chrome after implementing the fix only affect field-level topics.
I'm working on getting the code our web portal uses to call both page-level and field-level topics.
Copy link to clipboard
Copied
Here is the code our web portal uses to open page-level help topics and field-level help topics.
Page-level Help Topics
define(function (require) {
"use strict";
require('angular');
var navigationModule = require('navigation/js/navigation/navigation-module');
navigationModule.service('helpService', function ($sce, $interval, eventService) {
this.popUp = null;
this.getWindowHelpMapId = function (helpURI) {
if (helpURI) {
return helpURI;
}
return window.top.windowhelpmapid;
};
this.getHelpUri = function (helpLinkInfo) {
if(helpLinkInfo === null || helpLinkInfo === undefined) {
return null;
} else if (!isNaN(parseFloat(helpLinkInfo))) {
helpLinkInfo = this._getHelpMapIdUri(helpLinkInfo);
} else if (typeof helpLinkInfo === "string") {
helpLinkInfo = this._getExplicitUri(helpLinkInfo);
}
return (helpLinkInfo.domain + helpLinkInfo.path + helpLinkInfo.file + helpLinkInfo.parameters);
};
this._getHelpMapIdUri = function (windowHelpMapId) {
var uri = {
domain: eventService._getDomain(window),
path: "/availity/AvHelp/",
file: "whcsh_home.htm#",
parameters: "id=" + windowHelpMapId + ">>wnd=MainTopic"
};
return uri;
};
this._getExplicitUri = function (path) {
var uri = {
domain: eventService._getDomain(window),
path: path,
file: "",
parameters: ""
};
return uri;
};
this.openPopUp = function(uri) {
var self = this;
if(uri) {
self.popUp = $sce.trustAsResourceUrl(uri);
$interval(function () {
self.popUp = null;
}, 1000, 1);
}
};
});
return navigationModule;
});
Field-level Help Topics
We are in the process of redesigning the pages in our web portal. The redesign includes changing our development platform from Apache Wicket to AngularJS, As such, we have two sets of code for opening field-level help topics: one set of code for field-level topics opened from pages developed using Apache Wicket, and one set of code for field-level topics opened from pages developed using AngularJS.
AngularJS
function RH_ShowHelp(hParent, a_pszHelpFile, uCommand, dwData)
{
// this function only support WebHelp
var strHelpPath = a_pszHelpFile;
var strWnd = "";
var nPos = a_pszHelpFile.indexOf(">");
if (nPos != -1)
{
strHelpPath = a_pszHelpFile.substring(0, nPos);
strWnd = a_pszHelpFile.substring(nPos+1);
}
if (isServerBased(strHelpPath))
RH_ShowWebHelp_Server(hParent, strHelpPath, strWnd, uCommand, dwData);
else
RH_ShowWebHelp(hParent, strHelpPath, strWnd, uCommand, dwData);
}
Apache Wicket
public static String getHelpLink(int helpCode, String helpPagePath, String displayType, String linkText) {
StringBuffer buf = new StringBuffer();
buf.append("<a tabindex='-1' onclick=\"RH_ShowHelp(0,'/availity/");
buf.append(helpPagePath);
buf.append(">");
buf.append(displayType);
buf.append("', HH_HELP_CONTEXT, ");
buf.append(helpCode);
buf.append(");return false;\" href=\"#ShowHelp\">");
buf.append(linkText);
buf.append("</a>");
return buf.toString();
}
<%=HtmlUtil.getHelpLink(49, HtmlUtil.HELP_DEFAULT_PATH, HtmlUtil.HELP_DISPLAY_POPUP, "Availity Client Services")%>
Copy link to clipboard
Copied
Try the following update in your application:
parameters: "id=" + windowHelpMapId + ">>wnd=MainTopic"
Change it to:
parameters: "id=" + windowHelpMapId + ">>wnd=MainTopic>>newwnd=false"
Does this help?
Copy link to clipboard
Copied
Hello Willam,
Thanks for your reply. I'll try that code change to see if it solves the problem for my page-level topics. The code that calls the field-level topics is different than the code that calls the page-level topics. Do you have any suggestions on how I might tweak the code for the field-level topics?
Copy link to clipboard
Copied
Does Responsive HTML5 handle context-sensitive help topics (map IDs) differently than WebHelp?
We're planning to move our web portal's help system from WebHelp to Responsive HTML5. I published our help system in Responsive HTML5 format to a test server, and none of the context-sensitive topics open (whereas they had previously opened on the test server when they were in WebHelp format).
Copy link to clipboard
Copied
Responsive HTML5 works different with context sensitive help. You can still open topics directly, or you have to use a different call. By modifying the two functions, you can get it working again. For the full syntax, see; http://www.wvanweelden.eu/articles/context-sensitivity-responsive-and-multiscreen-html5
Copy link to clipboard
Copied
Hello Willam,
I started to suspect that the code we use in our web portal to call help topics only works for WebHelp.
I found the information about context sensitivity in RHTML5 on your website yesterday and I tried it out last night. It worked great, although I need to tweak it for field-level topics. For field-level topics, we only display the topic content without the left panel that houses the TOC, index, and search results. When I tried calling a field-level topic using the examples on your website, the window displayed both the topic content for the field and the left panel. For the field-level topic call, I tried using the rhwnd parameter with the field-level topic window that had been created in the project, but that gave me the same results. I'm going to try creating a new window in the project.
That leads me to my next, and hopefully last, questions. When I create a new window, RoboHelp asks me to select an output type, Responsive HTML5 or WebHelp. Regardless of the output I select, the Windows Properties dialog box for both output types is the same. Because the dialog box is the same, does RoboHelp differentiate between a WebHelp window and an HTML5 window behind the scenes?
Thanks,
George