Navto hyperlink bug

[#1]

I'm pretty sure this is a bug:

I have a banner with a link defined as "navto://collection/september_october_2016/article/so16_oow_preview". The banner is used on the "september_october_2016" collection browse page. In this context, the link sends the user to the first article in the collection, not the article named in the link.

If I put this same link on a banner in a different collection's browse page, it works fine. In other words, it appears that the "navto://collection/[collection_name]/article/[article_name]" format doesn't work if you are trying to point to create a link on a banner that points to the same collection that contains the banner.

This problem only occurs in iOS preflight apps, not Android preflight apps. I tested with version 2016.11 in both cases.

A "navto://article/so16_oow_preview" link works fine, but then I don't get the ability to swipe left or right to adjacent articles in the collection.

[#2]

So I've gone in and tried to reproduce this exactly.  I did have the banner in the collection it was referencing before as well. But for testing sake I created a new collection with a really long name, a new article with a really long name and put the navto banner in the collection pointing to that article. 

I did not publish the new collection or the new article. 

Using only preflight, I view my new collection and tap the banner and it goes right where I expect it to go. 

Not that this should matter but how many articles are in the collection where you are having the issue?  Is the target article off the first page in the browse page? 

I'm really at a loss as to why the one app would behave this way and the other would not.

[#3]

Jay, your note prompted me to test this in another, simpler test app that I have. And of course, it worked fine in that app! But, the levels of nesting of the collections and articles are exactly the same as the problem app. The only difference that I can determine between the 2 is that the app in which I'm having problems the collection is not yet published, where in my test app it is published and out of date. But in both cases I'm preflighting. The other difference is that my navto link is quite lengthy because the collection name is quite long. Is there perhaps some sort of restrictive character limit?

[#4]

As I mentioned in my first post, this is happening is custom preflight app builds, built with version 2016.11.

The problem exists on iPads and iPhones, but not Android devices.

I can verify that I'm using the article name and not the article title. I've tried this with several different articles, just in case there was some obscure problem with the article name, or it was being miss-typed or something.

In your tests, did you put the banner on the browse page of the collection that you are linking to in the banner? That is where the problem seems to lie.

[#5]

Keith,

[Note from tester]

I've tried to reproduce this on my end and am having no luck.  I've created two different banners in two different collections and they are using the navto link of navto://collection/<collection name>/article/<article name>

In both instances when I tap on the banner I get the article I expect and not the first article in the collection as you are seeing.
Can you tell me more about your setup.  What kind of device you are using?  What version of the viewer you have?  Have you verified the article id is being used and not the title?

Let me know and we can see what we can do.

Thanks,

Jay

[#6]

Keith,

I've tried to reproduce this on my end and am having no luck.  I've created two different banners in two different collections and they are using the navto link of navto://collection/<collection name>/article/<article name>

In both instances when I tap on the banner I get the article I expect and not the first article in the collection as you are seeing.
Can you tell me more about your setup.  What kind of device you are using?  What version of the viewer you have?  Have you verified the article id is being used and not the title?

Let me know and we can see what we can do.

Thanks,

Jay