RH8 > WebHelp > TOC won't render in IE8 via HTTPS - Fix/workaround?

[Shannongrey]

WebHelp projects generated with RH8 render perfectly via either HTTP or HTTPS calls to the server-hosted project in Firefox and Chrome.

The same projects render perfectly via HTTP calls in IE8.

But if the call to the project is via HTTPS, only the right pane content renders successfully. The left frame displays the Contents/Search tab in the project, but not the actual TOC content.

Does RH8 simply not support calling a WebHelp output through an HTTPS connection to IE8? Why does IE8 refuse to render the TOC through HTTPS, but it will render through HTTP just fine?

Does RH9 address this issue or is there a service pack for RH8 that addresses this issue.

[Shannongrey]

Update for anyone who is interested in this problem. RoboHelp 9 does not solve this problem either. It seems that RH8 and RH9 both generate WebHelp 5.50 and there are no functional differences in the Javascript that renders the TOC content.

We've spent many hours trying to debug this problem, and there seems to be no solution short of modifying the Javascript that renders the TOC content.

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.

[Shannongrey]

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.

[michael_hunsberger]

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).

Everything renders fine in Firefox 4. You mentioned modifying the Javascript that renders the TOC content. Any luck with that (we are getting kinda desperate at this point).

Thanks.

[michael_hunsberger]

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.

[Shannongrey]

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?"

Our best guess is that a recent Microsoft Security Update for their browsers has tightened security for SSL connections in a manner that makes certain Javascript functions unusable with IE. It's possible that it first appeared in IE8 but perhaps by now that same update has been propagated to other versions of IE too? Regardless, it's obvious that the Javascript for WebHelp is somewhat old now and it was not updated between RH8 and RH9. Both versions of Robohelp stamp their HTML files with "WebHelp 5.50" and stamp their .js files with "WebHelp 5.10.006".

[Shannongrey]

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.

Bottom line is that Adobe needs to figure out what's wrong with their Javascript for their WebHelp and fix it.

[michael_hunsberger]

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.

[Praful_Jain]

Hi,

I tried the same steps on the sample sales builder project provided with RH9,

1. Open sales builder project in RH9,
2. Generate WebHelp output.
3. Copy the published Webhelp output to Apache Tomcat wbeapps folder
4. Configure Tomcat to use my generated certificate for SSL
5. 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.

thanks

Praful Jain (praful@adobe.com)

Adobe RoboHelp Team.

[Shannongrey]

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.

[michael_hunsberger]

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.

[Shannongrey]

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.

[Praful_Jain]

hi,

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 praful@adobe.com. This will help us in root causing the issue.

thanks

Praful Jain

Adobe RoboHelp Team

[bap6]

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 v9.0.1.232

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

Results:

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

Please advise.

[rajibdugar]

If TOC/Index/Search is not working in IE7/8/9 via HTTPS, Please try the following steps

1. Go to https://acrobat.com/#d=WqbdTq-2R79ToU08-zfBEw
2. Download IESearchIssue.zip file. Unzip it.
3. It will create a folder IESearchIssue. It has two subfolders
   1. RH8.0.2
   2. RH9.0
4. If you are using RoboHelp 8.0.2, go to RH8.0.2 folder.
5. if you are using RoboHelp 9.0, go to RH9.0 folder
6. Go to <RoboHelp Install Folder>\RoboHTML\WebHelp5Ext\template_stock folder and rename the file whutils.js  to whutils.js.bak
7. Now paste the already copied new whutils.js in same folder.
8. Now again generate webhelp output of the required project.
9. Host it to your webserver and check if it works.

[Louisa_de]

https://acrobat.com/#d=WqbdTq-2R79ToU08-zfBEwhttp://

The link no longer works.

Is there any solution for that problem with RH 9?
I don't want to upgrade to RH 10. Far too risky at this stage.

[rlauriston]

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.

[Louisa_de]

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.

BR,

Louisa

[kms02]

We are also having this issue.

Anyone made any leeway as to how to fix both the search and TOC working in HTTPS?

[Shannongrey]

Long story short, after a very very very long amount of time spent convincing 2nd and 3rd level Adobe tech support that it was indeed a bug in their javascript for WebHelp, they finally provided us with a successive series of javascript replacement files for our WebHelp templates that first fixed only the TOC but not the search, and then the TOC and the search but broke the ability to view attached files (such as attached PDFs). We still haven't heard back from them regarding a true, final fix that indeed fixes the behavior of the Search and TOC without breaking the ability to click a link for an attached PDF and have it render successfully. In the meantime, we've simply refactored our WebHelp to use no attached PDF content out of desperation to at least get the original problem (non-functioning TOC and Search from SSL servers) corrected on our end.

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.

[Mary10]

Thank you for the update.

Have they posted the javascript replacement files for others to use?

I'll try your solution as well.

[anadublin]

Hi,

  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.

Any ideas?

Thanks

A.

[TanTurn]

Hi Shannon,

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.

Thank you,

Tannis

[rlauriston]

I have the same symptoms here.

I previously encountered the same symptoms with IE7:

http://forums.adobe.com/message/4281755

I never got it fixed before we dropped support for IE7.

[rlauriston]

My product manager is confident that this is a bug in IE8's JavaScript interpreter.