No combination of security settings in IE8 will enable IE8 to render the TOC successfully when the WebHelp is being delivered from an SSL server (via HTTPS). IE9, IE7, Firefox, Chrome, etc. all display the TOC just fine via HTTPS, but not IE8.
IE8 does render the TOC just fine when delivered via HTTP.
This problem effectively makes RoboHelp worthless for delivering help in a software-as-a-service (SaaS) environment for as long as IE8 remains "current" enough to be a supported browser for SaaS applications, because these typically require secure HTTPS connections. Air and FlashHelp are not viable alternatives because many enterprise IT organizations do not allow these technologies.
Another update: Checked with a colleague at another company and they're having a very similar problem. In our case, we choose to publish only the TOC and Search features for WebHelp. My colleague chooses to publish the TOC, Index, and Search features in their WebHelp. In their situation, the TOC content renders successfully over HTTPS, but their Index and Search features do not work. In our case, the TOC and Search features don't work over HTTPS.
We are having a similar problem. Generating using RH 8 from Framemaker files. Can't view the TOC, search, or glossary over SSL using Internet Explorer (any version).
One of our amazing Java gurus found a workaround that helps quite a bit. He modified the generated whver.js file by changing "var gbAIRSSL= false ;" to "var gbAIRSSL= true ;" This allowed the TOC and Glossary to render properly, but it will need to be modified manually each time.
Also, the Search function still doesn't work properly. This might be an Apache Tomcat setting issue. I'll update if we figure out more.
Thanks for the input, Michael. Seems strange that a variable clearly tied to Adobe Air would be affecting the behavior of standard WebHelp.
On our side, we've had a support ticket open with Adobe for nearly a week now, and just two days ago it was escalated to third level support. First level support was laughable and we immediately requested escalation. 2nd level had no answers but we were...um...surprised when they suggested "Have you considered using RoboHelp Server to provide your help?"
Okay, I just did some testing around that gbAIRSSL variable and can conclusively state that making that change breaks the search. The problem you're having with your search has nothing to do with your web server. To verify, open WebHelp locally on your own computer and try using the Search. If that variable is "false", Search works fine on your own local computer. If that variable is "true", Search no longer works on your local computer. I didn't bother my engineering group to put it all on an SSL box to test on our end whether messing with that variable fixes the TOC issue. We need the TOC and Search both working properly.
Thanks, we are going to test this afternoon. Worst case scenario at this point is that we remove the search functionality.
Glad to hear you all submitted a ticket. We contacted Adobe yesterday, but you are likely further along in the process. Hopefully they figure out a way to patch it.
I tried the same steps on the sample sales builder project provided with RH9,
- Open sales builder project in RH9,
- Generate WebHelp output.
- Copy the published Webhelp output to Apache Tomcat wbeapps folder
- Configure Tomcat to use my generated certificate for SSL
- Open the webhelp output in IE8
Everything was working as expected.
Please see the attached screenshot which shows IE8 loading the TOC correctly from SSL using apache tomcat server.
Praful Jain (email@example.com)
Adobe RoboHelp Team.
Thanks for posting your experience, Praful. However, I notice that you're publishing a WebHelp that looks significantly different from the standard WebHelp with tabs inside the left iFrame. I can't even guess at the WebHelp settings you use to achieve that look and feel--it doesn't match anything I remember WebHelp being able to look like. Are you sure you're not using WebHelp Pro? Try rendering your project using standard WebHelp with the Default skin.
Try publishing with only the Contents and Search enabled. Then try publishing with Contents, Index, and Search enabled. In the first case, nothing will work over SSL. In the second case, Contents might work, but Index and Search will be broken.
We've got a colleague in our city experiencing the same exact problems we are, and another person reporting the same issue on this thread.
Yes, thanks. Your response to my email was much quicker than I expected.
I would also be interested to know if you generated from a linked Framemaker or MS Word file. We had no problems generating from a linked Word file, but once we converted to Framemaker and linked the book file, the Webhelp ceased to work correctly over SSL.
We also used standard Webhelp with the Christi skin, with some slight modifications for look and feel.
And in our case, the problem occurs whether you've authored HTML topics natively in RH itself, or whether you've imported HTML topics from another authoring tool. In other words, we are not working with output from Word or FrameMaker--only with native HTML.
Can any one of you share the project or webhelp output where this issue is coming up. You can upload the files @ acrobat.com and share it to firstname.lastname@example.org. This will help us in root causing the issue.
Adobe RoboHelp Team
We are also having this issue.
Anyone made any leeway as to how to fix both the search and TOC working in HTTPS?
Terrible tech support, terrible follow-up, and very time-intensive. These days I would counsel anyone to stay away from Robohelp because it is given substandard support and does not receive timely updates to stay current with the changing web standards.
Thank you for the update.
I'll try your solution as well.
I have the opposite problem, we use WebHelp Pro, and the TOC displays fine in IE8 when accessing the page internally to the webserver or externally via Apache. But on Firefox, the TOC only displays when accessing the page internally, if accessing externally the left side is empty.
we are also experiencing the same issue. we even upgraded to RoboHelp 9 and it didn't fix the problem.
Below are project settings:
RoboHelp Html v184.108.40.206
WebHelp project -> Generate
Content -> Language > English (US)
Encoding: Unicode (UTF-8)
Map Files: None selected
Navigation Tab -> Skin = Traditional Style - no skin
Preferred Format = DHTML > Pure HTML
Toolbar Buttons > TOC, Search
Synchronize Table of Contents Automatically
Left TOC Contents does not show up
Left Search does not work
One other note: It works on some XP ie8 machines and others it does not work. FYI
If TOC/Index/Search is not working in IE7/8/9 via HTTPS, Please try the following steps
- Download IESearchIssue.zip file. Unzip it.
- It will create a folder IESearchIssue. It has two subfolders
- If you are using RoboHelp 8.0.2, go to RH8.0.2 folder.
- if you are using RoboHelp 9.0, go to RH9.0 folder
- Go to <RoboHelp Install Folder>\RoboHTML\WebHelp5Ext\template_stock folder and rename the file whutils.js to whutils.js.bak
- Now paste the already copied new whutils.js in same folder.
- Now again generate webhelp output of the required project.
- Host it to your webserver and check if it works.
Can I ask if the HTTPS server is exclusively SSL? Or does it support both. I am having a similar problem with FireFox 3.6 +, but only on a system running on a server that is SSL exclusive.
I installed a trial version of RoboHelp 10, and that fixes the problem for me.
Directly as a result of encountering this bug, I'm in the process of migrating from RoboHelp to WebWorks ePublisher. It's more flexible, easier to use, and the output looks exponentially better. A one-year subscription is the same price as upgrading from TCS 3.5 to 4.0.
So I guess you're working with FrameMaker and used to import the files into RH?
We have native RH files, as far as I understand they cannot be migrated to WebWorks.
In the long run we'll probably go DITA >> oXygen. Away from RoboHelp, from Adobe even if possible.
But that's no short term solution which I would really need now.
I might try the RH 10 trial version, just to cope with this release if nobody has a better idea.