Customer Portal

Get Involved. Join the Conversation.

Topic

    Richard Keevil
    search/KeywordText + Anchor issuesAnswered
    Topic posted July 20, 2016 by Richard KeevilGold Trophy: 10,000+ Points 
    363 Views, 6 Comments
    Title:
    search/KeywordText + Anchor issues
    Content:

    I noticed that in Chrome (51) and FF (49) external anchors don't work well with answer/detail.

    I stripped out a template to contain the skeleton tags and 2 widget calls (below) when initial_focus is true, anchor navigation fails, when I set it to false, anchors work fine.

    "initial_focus" kinda makes sense, but I don't think it should be hijacking anchoring.  

    Thoughts on workarounds?

    Version:
    16.2
    Code Snippet:

    Best Comment

    Richard Keevil

    This issue was being caused by a self inflicted bug in a customised search widget.

    Comment

     

    • Barrilito van Dijk

      Hi Richard,

      I try to understand what you are saying. You are speaking about a KeywordText widget and you are speaking about anchors in a detail page. Do you mean with anchors, the hyperlinks to external pages, links like <a href="http://externallink.com/page.html">, correct?

      If so, then I don't understand your example. What do you mean with "anchor navigation fails"? Are the links not working anymore within your answer detail page? That means if you click on it nothing happens? If so you are talking about links within the answer, correct?

      Please confirm if above is correct as it is rather strange.

      ps. placing html comments (<!-- -->) on a widget has no use and is bad practice, the widget can still be loaded, only the output is within the html comment, so things are still loading behind the scenes...

      Regards.

    • Richard Keevil

      When creating an answer, you can add and manage in page anchors.  When you want to navigate to that portion of your answer from another answer or another source, you can specifically refer to a page anchor such as http://externallink.com/page.html#anchor

      However, if your answer/detail template uses KeywordText widget for something like a search box and its initial_focus is true (as you may want to encourage the cursor to default to said search box), then the anchor will no longer navigate to the anchor in the browsers I mentioned.

      My snippet shows the minimum template structure needed in order to demonstrate the issue. I highlight the key widget usage using <!-- --> which can be used to toggle the use of initial_focus="true" and initial_focus="false"

    • Barrilito van Dijk

      Hi Richard,

      I understand the case better now, thanks. Tried it in may16 for you, can't reproduce this however. It seems weird because the link itself does not change whether a focus is set to a field or not. 

      When you hover over the link does it show the entire url including anchor? Is it clickable? (as you say it does not navigate to the anchor, I think you mean that it opens the link but looses the anchor data, or does it not navigate at all to a page)?

      Strange one this!

      Regards.

    • Richard Keevil

      Yeah this one is a bit odd.

      The link itself is correct in all cases.  The best way I have now found to replicate it, is to open one of the browsers and in a new tab, copy and paste a test answer URL with the #... so that you are emulating anchor linking from an external source - like an email or something.

      Oh and if you also then actually replicate the problem, but then return focus to the URL bar and press enter, it scrolls down - once!

      Oddness-indeed... :/

    • Barrilito van Dijk

      Hi Richard,

      I really don't know what could be the cause. I did some search in google on chrome and hashes/anchors and I came on a post where someone said chrome has issues with anchors and focus if the page anchor does not have a tabindex. It should have one like so:

      <a href="#" tabindex="-1">Example</a>

      No idea if this solves anything, perhaps try it!  Good luck.

      Regards,

    • Richard Keevil

      This issue was being caused by a self inflicted bug in a customised search widget.