minitoc links > open in new tab

[pdenchfield]

Hi, if I click a minitoc link, it works as expected. But if I right-click and select Open in new tab (or copy link to use in new tab), I get a 404 on our help site because the server seems to think the page doesn't exist, even though it does! The only difference seems to be the omission of the pound/hash sign (#), but that should work anyway, right?

Here's an example of the URL differences.
Source page with minitoc links: https://help.nintex.com/en-US/o365/#o36 ... cuSign.htm
Clicked link: https://help.nintex.com/en-US/o365/#o36 ... s%7C_____1
Copied link: https://help.nintex.com/en-US/o365/o365 ... s%7C_____1

EDIT:
1. The above copied link works fine when the TocPath part is trimmed off the URL (everything after the .htm). It should work regardless.
2. Other links that were inserted as XREFs work fine when copied - no need to trim the URL.

Thanks,
Pamela

[kgdyall]

I saw the same thing - it came to our attention as a customer issue.

I suspect the problem is that the javascript that constructs the TOC (and the mini-TOC) assumes that the topic will be opened in the same page. So when I right-click on a link and open in a new tab, it works just fine for a link that's not in any kind of TOC. The page opens as a simple single page, with no top or nav pane (I'm using tripane HTML5 output). However, when I right-click on a TOC link and choose to open it in a new tab, I get the 404 error. The difference in the URL is that it's missing the #<main page>, just as yours is missing the #. I also see the same behavior you see with removing the TOC path. I think this could be due to the browser trying to set the path in something that doesn't exist, because the link is to a plain page, not the main page that defines the frames (or panes). So there's no pane for it to update in the plain page.

Not sure how easy it would be for the javascript to pick up the context from the browser - can it query the browser to find out where the link will be opened?

[kgdyall]

This appears to be a regression in the Flare software. Our November 2017 release has the problem; the August 2017 release does not, neither do earlier releases. I'll file a bug report.

[pdenchfield]

Thanks for your message. Turns out this is a known issue, at least with 2017r3. MadCap Technical Support "submitted an issue report" under the number 134180.