Hi all,
So, I called support. They confirmed that there is a bug that if you deliver your webhelp through an iFrame, the TOC won't synchronize. While of course, they have no insight into when it will be fixed (grr, the biggest problem with Madcap that they offer their customers NO insight into what is coming, what is going to be fixed, what is admittedly broken).
To that end, does anyone know of a workaround to get the TOC to synchronize with topics if delivered through an iFrame?
Please and thank you in advance.
WebHelp iFrame bug fix?
Re: WebHelp iFrame bug fix?
We ran into this months back when we implemented our HTML5 output via an iframe in our product.
We experimented in part with the Mini-TOC proxy. To memory, the proxy does correctly synchronize, but in the end we just opted to hide the TOC automatically when the skin loads in a frame.
I setup our project so it displays differently in a frame, rather than when viewing it directly on the web. It's all Javascript driven, but inelegant. The user is given an Open In New window button when viewing the help in a frame, if they want to have the TOC synchronize.
A fundamental bit of the issue appears to be that the synchronization is driven by the window.top URL, rather than the window.parent URL (I'm paraphrasing liberally). However, in talking to someone at MadCap, this is apparently a symptom of a larger issue. So, unfortunately, they gave me the same answer that you got, which is nothing concrete.
We experimented in part with the Mini-TOC proxy. To memory, the proxy does correctly synchronize, but in the end we just opted to hide the TOC automatically when the skin loads in a frame.
I setup our project so it displays differently in a frame, rather than when viewing it directly on the web. It's all Javascript driven, but inelegant. The user is given an Open In New window button when viewing the help in a frame, if they want to have the TOC synchronize.
A fundamental bit of the issue appears to be that the synchronization is driven by the window.top URL, rather than the window.parent URL (I'm paraphrasing liberally). However, in talking to someone at MadCap, this is apparently a symptom of a larger issue. So, unfortunately, they gave me the same answer that you got, which is nothing concrete.
Re: WebHelp iFrame bug fix?
Not a quick workaround to implement, but wouldn't using the new top navigation option in Flare v11 work? There isn't actually any TOC synchronization because you're not using the tripane help layout. It should save you some real estate so you can show more of the help, although that kind of depends on how you're displaying the help in your app. Or is that what you meant MattyQ about "HTML5 output" and the mini-TOC?
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
Re: WebHelp iFrame bug fix?
I wish it was. We were constrained to the tripane, so we were stuck trying to find a workaround with that skin.
Lisa's right, though. The most sensible thing, if you're not stuck using the tripane, would probably be to switch over to the topnav.
Lisa's right, though. The most sensible thing, if you're not stuck using the tripane, would probably be to switch over to the topnav.
Re: WebHelp iFrame bug fix?
Can't use top-nav, our UX/UI folks have decreed a left-nav TOC.
I'm trying to push the argument for removing the help from an iFrame and opening in a new modal window. We'll see.
I'm trying to push the argument for removing the help from an iFrame and opening in a new modal window. We'll see.