Menu proxy issues in 2017r2

[NorthEast]

I discovered a serious bug in the menu proxy, and some changes to how menu proxies (and top nav menus) work in 2017r2.

* There's a bug where Flare will ignore the TOC that you selected in the menu proxy. The menu proxy will always use the target's default TOC, regardless of what TOC you select.
This bug is particularly annoying for us, as it means we can't use 2017r2.

* Menu proxies (and the top nav menu) are now generated dynamically at run-time. They're not generated added at build-time, i.e. you can no longer see the links in the generated HTML source.
This is a problem for us, and might affect others that tweak the menu proxies (which is our risk, I know).

This second change is probably beneficial for file size, although I'm not sure if it's good for search engines. I thought one of the benefits of top nav over tripane was that having the navigation links in the HTML page source meant that search engines could crawl the pages and find all the navigation links. If the top nav menu and menu proxy links are now added dynamically using a script, doesn't that mean search engines will not 'see' these links any more? (I know you can still add a sitemap, and it's what I'd recommend doing anyway.)

[nielsf]

I'm using a script that uses the menu structure to create a slide-out menu (menu is shown when you click a toolbar button; scrolls to the current menu item). That doesn't work anymore in 2017r2 (the menu content does slide in, but is just a blank waste of space with no links or anything).
This is probably the reason - that the menu is generated at runtime. Don't you think..?

[NorthEast]

I'm using a script that uses the menu structure to create a slide-out menu (menu is shown when you click a toolbar button; scrolls to the current menu item). That doesn't work anymore in 2017r2 (the menu content does slide in, but is just a blank waste of space with no links or anything).
This is probably the reason - that the menu is generated at runtime. Don't you think..?

The menu links should still be generated by Flare, however note that the bug means it will only generate the proxy using the target's default TOC - it will ignore whatever TOC you specified in the menu proxy.
So if your menu proxy is context sensitive, and the topic isn't included in the target's default TOC, then the menu isn't generated because it doesn't include that topic.

The menu links being created at runtime is only a problem if your script is looking for the HTML code that's generated inside the menu. As your script is probably running before the menu proxy HTML is created, then your script probably isn't going to work.
If you look at the page using View Source in the browser, you'll see that the menu proxy is empty; e.g.

Code: Select all

<ul class="nocontent menu ...> </ul>

And if you look at the live code of (a working) menu using browser tools (press F12), you'll see that the Flare scripts have added the links at runtime.

[nielsf]

Hi,
Thanks for the answer. That's the thing - all the menu items are there, they just don't get shown. So somehow the script does not turn on the visibility correctly. Perhaps a timing issue, or some class changed its name (like the tab-bar-section changed its name to title-bar-section ).

So - I've got some script-digging to do...

[NorthEast]

Hi,
Thanks for the answer. That's the thing - all the menu items are there, they just don't get shown. So somehow the script does not turn on the visibility correctly. Perhaps a timing issue, or some class changed its name (like the tab-bar-section changed its name to title-bar-section :shock: ).

So - I've got some script-digging to do... :)

Ok, we might not be talking about the same thing.

This post was about the menu proxy structure in Flare, which is different to the menu in the top nav header (which has the 'tab-bar' class).

If you're doing something with the top nav menu, then I don't know exactly what has changed. I do know that Flare has restructured things a little, so the class names or the HTML structure may have changed. Flare is now also using Foundation 6.2 instead of 5.5.

[NorthEast]

I found another bug when using menu proxies in 2017r2.

The setting When merging, replace node with merged TOC does not work all the time.

It only seems to work when the nested TOC (to be merged) is inside the target's main TOC. It doesn't work if the nested TOC is inside a TOC which is not the main/target TOC. It doesn't replace the merged node, so it displays the TOC filename rather than the topic in the TOC- so therefore gives you a dead link in the TOC proxy.

[asbahr+]

Hi,

Does anyone know if the Menu Proxy issue was addressed in the 5/31/2017 update to 2017 r2? I read through the release notes and it doesn't seem like the issue has been fixed.

Any information you can provide would be helpful.

Thanks,
Ana

[kgdyall]

I'm seeing exactly the same issue with the menu proxy - it uses the default rather than the one specified.

[NorthEast]

Does anyone know if the Menu Proxy issue was addressed in the 5/31/2017 update to 2017 r2? I read through the release notes and it doesn't seem like the issue has been fixed.

The two bugs I mentioned have been fixed:
* There's a bug where Flare will ignore the TOC that you selected in the menu proxy.
* The setting When merging, replace node with merged TOC does not work all the time.


Menu proxies (and the Top Nav menu) are still generated dynamically at run-time, so if you use scripts to modify the content of these menus, then you'll probably have to adjust your scripts.

[RNTHelpWriter]

I've read through this discussion and I'm not sure that I saw anyone raise exception to the following new behavior.

Because of the new dynamic menu rendering, it seems that when you land on a topic using a bookmark in your url, you will get a different rendering of the menu proxy than if you did NOT use the bookmark. This makes no sense to me. I'm trying to convince MadCap that this is not desired behavior. Can anyone tell me why this would be desired?

Here's a more detailed description. If you have multiple bookmarks on a page and each bookmark is represented as a child node in the TOC, going to the page without the bookmark in the url (in other words, the base topic), a side menu will render all bookmarks on the page (they are all siblings in the TOC). However, if you use a bookmark, then the side menu only shows that bookmark ignoring other siblings. Also, the bookmark is included in the breadcrumb. I don't know why this would be desired. That side menu should be static; it should appear the same way no matter how you get to the topic, with the exception that the active bookmark should be bold (or however you've styled it). Here's a visual:

Without bookmark in Url:



With bookmark in url:

[RNTHelpWriter]

I find it surprising that no one has been negatively impacted by this changed behavior in the menuproxy. I guess no one is using bookmarks in their navigation because when you do, side menus render differently.

Would really appreciate some feedback on this and would like to know if anyone else has be impacted by this. MadCap has logged it as a bug (#134505) but don't appear in a hurry to fix it.