IE10 Fix Does Not Appear to Work for My WebHelp Pro Project

[Bernadino50]

I am testing a WebHelp Pro project that was originally created in RH9, but is now being generated in RH10.0.1. (I am working on a Windows 7 (64-bit) OS, with IE10.) With the RH application closed, I copied the two "FixForRH10Install" folders into my WebHelp5Ext folder, as directed. Then, after reopening the app, I recompiled my project. Unfortunately, whether I view my primary layout locally or publish it to a server, I still see the same problem with the output in IE10. Initially, I see the TOC panel on the left and the default topic on the right. But if I click a link in the topic, in the TOC, in the Index, or in a Search result, I get nothing in the right side of the screen--just a blank with progress "swirl" endlessly swirling. (For what it's worth, if I right-click in the blank screen or on a TOC link, the topic will finally display.)

Is anyone else experiencing this? Even with this "fix," the only way I can make my Help display properly is to use IE10's Compatibility View. 

[Peter Grainge]

Did you paste the folders to the WebHelp5Ext or to the same name folder within? The latter is not the correct procedure.

You have to drag the supplied folders to where I have shown, you do not paste them over the top of the old template_skin and template_skinpreview folders. When you drag to the correct location, you will be asked if you want to merge the folders, confirm you do.

If you have dragged to the old folders, sub-folders will have been created that you need to reverse out.

The template_skin folder should not have any sub-folders.

The template_skinpreview folder should have a template_skin sub folder but that should not have any further sub-folders.

The patch does work once you have regenerated so I am pretty sure that is where you problem is. If you are not sure about all this, you may want to get IT or a developer to assist. Whilst it will not impact this problem, also make sure you have applied the recent patch.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Message was edited by Peter Grainge to clarify first paragraph.

[Bernadino50]

I can see where duplicated folders within folders would be a problem, but that is not the case here. I pasted the two folders to the WebHelp5Ext fold, so there were no duplicated subfolders.

Just to be sure that I did everything right, I went back and deleted the template_skin and the template_skinpreview folders from the WebHelp5Ext directory. Then I returned the original

template_skin and the template_skinpreview folders to the WebHelp5Ext directory. (I had copied these off to another location at the beginning of this process.) I verified that the files contained in these folders were in fact the "old" ones by checking the whtbar.jsfile date (7/4/2012 in the old folders and 4/10/2013 in the new folders). Next I dragged the folders supplied by Adobe to the WebHelp5Ext directory and answered the merge and copy/replace questions. I then confirmed that the file date now displayed was the "new" date. But when I opened RH and regenerated the project, I still observed the undesireable IE10 behavior.

Other troubleshooting efforts:

• I've reviewed the properties of the "supplied" files to make sure that none were set to "Read-only" (in case this made a difference). None were.
• I've cleared the IE10 cache several times, to no avail.
• I've reset my IE10 settings to the program defaults and restarted my machine. Still no go.

While my situation may very well be the result of "user error," I can't see what I'm doing wrong. Any additional suggestions will be appreciated.

[Willam_van_Weelden]

Hi,

In order to rule out a user error, try the following:

1. Open whtbar.js and check line 709. It should be:

else if(sType=="hide2" && navigator.appVersion.search("MSIE 10.0") == -1)

2. Open whskin_frmset01.htm and check line 108. It should be:

if (oFrameset && navigator.appVersion.search("MSIE 10.0") == -1)

Do the lines in both files match the above text?

Greet,

Willam

[Bernadino50]

Hi William,

For the whtbar.js file in the ...\WebHelp5Ext\template_skin folder, the referenced information is indeed found on line 709. However, in the ...\WebHelp5Ext\template_skinpreview\template_skin location, the referenced info is found on line 706.

As for the whskin_frmset01.htm file... I do not have a file with this name, and this is not one of the "supplied" files. Did you, perhaps, mean whst_frames.xml? If so, in both affected folders, the referenced information is found on line 124, not 108.

So what does this tell us?

[Willam_van_Weelden]

Hi,

Sorry for the confusion, I was checking to see whether the could would be present in your output (hence the whskin_frmset01.htm instead of the XML file).

If the code is present in your output, it seems that you applied the patch correctly. And thus it would rule out a user error. From what I can see know, it that this patch doesn't fix IE10 for WebHelp Pro.

Greet,

Willam

[Peter Grainge]

That can be checked by generating WebHelp and putting it on a webserver but not within RhS. If Willam's theory is then proved, we can take it up with Adobe.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Bernadino50]

After muchmore testing, I've come to the conclusion that the issue is somehow related to my machine and our corporate network--not the fix or whether the output is generated as WebHelp or WebHelp-Pro. In a nutshell, when my machine is connected to our corporate network, my projects do not display correctly in IE10--regardless of the WebHelp output. Inexplicably, on a co-worker's laptop, connected to the same network, the projects work as expected. Then, when I connect to the Internet via a non-corporate wireless network or through a VPN, the projects seem to behave perfectly in IE10, on my same machine. (Cue the Twilight Zone music.)

I'm not sure what's going on, but at this point it appears to be a matter for my IT department.

Thanks Peter and William for your kind and prompt assistance!

[Peter Grainge]

I spoke with Adobe on this today. Hope to advise you more tomorrow.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Peter Grainge]

@Bernadino50

Is your server's OS is Windows 2008?

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Peter Grainge]

Ignore last question about server OS. I have spoken to Adobe about this issue and will post tomorrow with details of a potential cause and the fix.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Peter Grainge]

For most people the IE10 fix will work. There are two known scenarios where it will not.

The first scenario is if the end user is viewing from a machine with Windows 2008 Server as the operating system. This is not a normal scenario. The solution is for the end user to enable the JavaScript by adding the webhelp as a Trusted Location in IE10 settings.

The second scenario is where the administrator who controls the host server sends any IE compatibility meta-tags. In this scenario the necessary Javascript settings in the Adobe IE10 fix will not be applied. Hence, the server should be configured not to send any IE compatibility meta-tags.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[JGaf]

So I'm not normal.....

How would one go about enabling the js by adding webhelp as a trusted location in IE10 settings.  I don't know how to do this (but I really tried)....

Our webhelp docs are not stored on a server at customer sites, so this is a major issue.......

thanks!

[Peter Grainge]

Hopefully I can answer your question but I'm sorry I will not be able to change the fact you are not normal.

If IE10 is the same as 9 go to Internet Options in Settings and click the Security Tab. There you will see Trusted Sites.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Bernadino50]

Thank you, Peter, for looking into this issue so persistently.

In most instances, my WebHelp project does display correctly (with the Adobe IE10 fix), and in those situations where it doesn't, IE10's Compatibility View seems to be an easy workaround. I do, however, appreciate having the information about those two problematic scenarios you describe. We will add your troubleshooting tips to our support wiki.

Thanks again.