HTML help will not start when IPv6 address used in the URL

[spackiaraj]

If URL has IPv6 address then HTML help page is not getting displayed.

For instance, if the URL is http://[::1]:8080/html/uihelp/wwhelp_Left.htm#CSHID=helplibrary, then help page does not appear. This happens only in IE (all versions). It works well with other browsers.

This is because, Madcap tries to compute the URL in of the JavaScript (MadCapUtilities.js), which uses 'document.location.host' to get the host information.

For the above case, IE returns ::1:8080 as value for 'document.location.host', where as other browser returns [::1]:8080. Of course its a bug at IE, but it impacts our customers (help does not come up)

What we would like to know is that can we modify the affected JavaScript so that our customer will get quick fix?

The possible patch follows
====
---Content/SkinSupport/MadCapUtilities.js
226a227,231
> // IE bug: IE clips [] from host
> if (navigator.userAgent.indexOf('MSIE') >= 0 && bodyLocation.href.indexOf(bodyLocation.protocol+"//[") == 0) {
> bodyHref = bodyLocation.protocol + (!FMCIsHtmlHelp() ? "//" : "") + "[" + bodyLocation.hostname + "]:" + bodyLocation.port + bodyLocation.pathname + bodyLocation.hash;
> }
>
236a242,245
> // IE bug: IE clips [] from host
> if (navigator.userAgent.indexOf('MSIE') >= 0 && currLocation.href.indexOf(currLocation.protocol+"//[") == 0) {
> href = currLocation.protocol + (!FMCIsHtmlHelp() ? "//" : "") + "[" + currLocation.hostname + "]:" +currLocation.port + currLocation.pathname;
> }
====

Do any one see copy right violation with my patch

Thanks in advance

[rob hollinger]

spackiaraj,
Those changes in the output would be fine.
One thing we ask is after this is done, to document the problem and work-around. Then send it to us so we can take a look at whats going on and see if there is anything we can address in the future.

Submit the information here:
http://www.madcapsoftware.com/bugs/submit.aspx

[owenf]

Hi Rob, Spackiaraj,

we also encountered this, with Flare 6, and patched madcapall.js in a similar way. we're using flare 7 now, the bug has resurfaced, and we'd like to repeat the patch. Is your fix in madcaputilities.js specific to flare 7, or ? I'm asking because i'm not a js expert and it's hard to know whether madcap moved the functions from place to place - it would help to know where to point my dev colleagues to do the patch.

thanks
owen

[owenf]

does anyone know if this is still present in flare 9?