TOC Panel Issue with IE 10

[Mishou6779]

Sorry to be blunt but we're all short on time, so here's an ordered list of what one of my readers reported to me:

1. The user opens the help, then clicks the Show navigation icon.
2. The TOC displays in the left panel as expected (with the full list of TOC links).
3. The user clicks a TOC link and the help topic associated with that link displays in the left panel. It is not supposed to do that. The help topic is supposed to display in the right panel, and the TOC list should display in the left panel.

Other facts:

- Output is WebHelp
- WebHelp was created in Flare V8
- WebHelp output works correctly in Firefox (I tested it in version 20.0.1)
- WebHelp output works correctly in Chrome (I tested it in version 26.0.1410.64 m)
- WebHelp output works correctly in IE 9 (I tested it in version 9.0.8112.16421)

I have attached two images. The first one illustrates what is wrong. The second one illustrates how it is supposed to look.

1 for Flare Forums.png

2 for Flare Forums.png

[doc_guy]

Have you opened a support case with MadCap? Is this true for all links in the TOC, or does it only apply to some links?

[Mishou6779]

Confirmed with the user that the TOC works as expected with Heading 1 links. It's with the Heading 2 links that she starts seeing that problem.

[doc_guy]

I'd submit this as a bug (if you don't have a support contract), or I'd open a support case if you do have a maintenance contract. This looks like a big in WebHelp output that needs to be looked at.

https://www.madcapsoftware.com/feedback/bugs.aspx

[ToddPh]

Does the problem still occur if you turn off the compatibility setting for the page? (the blue broken page icon in the address bar)

[Mishou6779]

Thanks doc_guy, and ToddPh!

I had the user test ToddPh's suggestion, and sure enough, when she turned off the compatibility mode, my online help TOC worked perfectly.

PHEW! (I'm sending mental love notes to Microsoft. *L*)

[LTinker68]

Make sure you do submit a bug report to MadCap. There might be legitimate reasons why IE might need to run in compatibility mode, and that behavior shouldn't happen, regardless of what heading level is used.

[pascales]

I too am experiencing this issue. We can't ask our users to turn off Compatibility View in case they need it. Does anyone know of another workaround?
We are using Flare 7, and could possibly upgrade to v9 if that would help.
Thanks!

[whunter]

I reported the issue to MadCap a while back, and they told me to add the following meta tag to default.htm, default_left.htm and default_csh.htm:

<meta http-equiv="X-UA-Compatible" content="IE=edge"/>

Basically the tag "overrides" compatibility mode for the web site.

However, please do report it to MadCap -- it is a pain to need to manually add this each time I generate the help, and I'm hoping that if more people complain then it will get attention.

[LTinker68]

However, please do report it to MadCap -- it is a pain to need to manually add this each time I generate the help...

Did you try adding that code to the masterpage, or does it get stripped out at build-time?

[whunter]

I just tried it -- it appears to get stripped out.

[NorthEast]

However, please do report it to MadCap -- it is a pain to need to manually add this each time I generate the help...

Did you try adding that code to the masterpage, or does it get stripped out at build-time?

I just tried it -- it appears to get stripped out.

The master page is only used by topics though, and does not effect those files you mentioned - default.htm, default_left.htm and default_csh.htm.

[LTinker68]

The master page is only used by topics though, and does not effect those files you mentioned - default.htm, default_left.htm and default_csh.htm.

I know, but I thought if it was passed in the masterpage then the code would be in the resulting topics and should still work to resolve the issue. Easier than having to edit the default pages every time.

That said, I don't think the default pages themselves change from build-to-build, so an alternative is to make the edits to each file once, then copy those files to a location outside of the project. After building the output, copy those modified files back into the output folder to overwrite the ones just created during the build. That's easier than opening the files and adding the tag each time. Enterprising souls could probably even write a script, batch file, whatever, to do that automatically after each build.

[NorthEast]

The master page is only used by topics though, and does not effect those files you mentioned - default.htm, default_left.htm and default_csh.htm.

I know, but I thought if it was passed in the masterpage then the code would be in the resulting topics and should still work to resolve the issue. Easier than having to edit the default pages every time.

Yep, but it wouldn't matter if the meta tag was in the topics, as you don't directly open the topics in the browser (for WebHelp/HTML5). The meta tag needs to be in the default.htm files, as it's these files that you open in the browser, which in turn display the topics in a container frame (WebHelp) or iframe (HTML5).

Incidentally, you can add meta tags to the master page and they don't get stripped out of topics.

[luvthepug]

I too am having the same problem with IE 10 (I'm using Flare V7). I added the meta tag as instructed to the three files. The TOC behaved properly except that once a topic link in the TOC is clicked, it remains highlighted as if it's the active topic. The highlight should "turn off" once another topic link is selected. Here is an example.

Capture.PNG

[whunter]

Yeah it does that in IE 10. I haven't bothered logging it as a bug yet but I suppose I should.

[whunter]

I logged a bug with MadCap and they informed me this issue is fixed in v9. I downloaded a trial version to test it out and it does appear to be fixed in v9.

[Psider]

You could add the meta tag to the source file in the Flare installation directory, however, there is no guarantee this will survive upgrades, etc and will affect every project you compile.

The files are located in the installation directory under Flare.app\Resources\<your output type>\Desktop

e.g. for HTML5, Flare.app\Resources\Webhelp2\Desktop

Take a backup of the existing files and USE AT YOUR OWN RISK.

Amber

[bala123]

Hi,

I have downloaded the trail version of Flare v9. But still I couldn't see any resolution to this issue, and I see as the issue persists.
Can anyone help me on this.

Thanks.
~B.

[whunter]

Sorry, to clarify: the secondary issue where multiple items get selected in the TOC is fixed in Flare 9. But the issue where topics open in the TOC when using IE 10 in compatibility mode still exists.

[bala123]

Thanks for your response,

I have observed in my testing that, the issue is happening in both the cases( Compatibility mode On & Off).
I want to know one thing that, when you are planning to provide the fix to it?
kindly share the information.

Regards,
~B.

[LTinker68]

I want to know one thing that, when you are planning to provide the fix to it?

This is a peer-to-peer forum, as it indicates at the top of the screen. We have no idea when MadCap will be implementing bug fixes or feature requests. If you want to know the status of a bug, you'll have to contact MadCap Support directly.

[SMerrill]

Just wanted to point out that this IE 10 issue still exists in Flare 10.