• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 4.x Series
    • Bug
    • [4.1.1] Issues with jumping to section headings: 1) Clicking the same TOC item more than once, 2) At page load (sometimes)

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: [4.1.1] Issues with jumping to section headings: 1) Clicking the same TOC item more than once, 2) At page load (sometimes)

    • Issue Tools
      • View Changes
    1. issueid=6157 January 28, 2021 11:09 AM
      ACL ACL is offline
      Regular Member
      [4.1.1] Issues with jumping to section headings: 1) Clicking the same TOC item more than once, 2) At page load (sometimes)

      On VaultWiki.org's XF wiki demo site, jumping to a heading section fails in two different scenarios.

      1) When clicking the same Table of Contents (TOC) item a second time. If a heading's anchor is already part of the current page's URL, nothing happens when clicking the TOC link associated with that same heading.

      At the surface, changing this functionality might seem unnecessary. But imagine that someone has used the TOC to jump to a particular heading section. They then click XF2's floating 'return to top' button but decide that they want go back to the same section. They click the same TOC item as before and so they experience the issue. XF's 'return to top' button does not change what is written in the address bar, whereas clicking a TOC link does. It makes no difference whether they scroll up manually as the situation is the same.



      2) Sometimes at page load despite the browser address bar having a matching anchor. With what seems to vary between device and/or browser, arriving at a wiki page with a initial anchor in the path (such as via a wiki link using the wiki="page|#section" bbcode) results in the desired section never being jumped to without further user action.

      I can kind of reproduce this issue, but not reliably. For testing purposes, I have added two links to the page Template:ParseBBCode (N.B. this is a reused old wiki page so the title is irrelevant). The two links point to the first and second headings on the Testing playground for XF2 page. What happens when you click through from either of these links?

      On a Windows 10 desktop, with Mozilla Firefox link 1 failed to jump to the heading. Link 2 worked fine. On that same computer, with Google Chrome neither links 1 or 2 automatically jumped to the desired section the first few times I tested. Confusingly, I have repeated the test on a different day with this same computer and on that occasion link 2 did jump to the heading (but not link 1). Repeating a few more times one after the other, link 1 continued to not jump to the section.

      Oddly enough, on an older PC running Windows 7, for Mozilla Firefox and Google Chrome they both correctly jump to the linked-to heading section . Same success with Google Chrome on Android, albeit after a momentary delay.

      Scratching my head with this one! Perhaps this is something that could benefit from other VW customers chiming in if they've experienced the above to try and identify similarities with device, OS and/or browser...


      ----


      In an earlier report I mentioned that a couple of my site's visitors were experiencing problems with TOC links not working. At the time I thought the most likely scenario was a scroll delay, but now I am not so sure. Here is my theory. Perhaps these visitors arrived at the destination wiki page via a link pointing to a precise section where for whatever reason the section did not ever automatically scroll into view (part 2 of this report). Subsequently they clicked on a TOC item for the same heading but that also failed to scroll (part 1 of this report).
    Issue Details
    Issue Number 6157
    Issue Type Bug
    Project VaultWiki 4.x Series
    Category Headlines / Sections
    Status Fixed
    Priority 3 - Loss of Functionality
    Affected Version 4.1.1
    Fixed Version (none)
    Milestone (none)
    Software DependencyXenForo 2.x
    License TypePaid
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. January 28, 2021 2:52 PM
      pegasus pegasus is offline
      VaultWiki Team
      For part 1, I believe I can confirm this as described.

      For part 2, the issue appears to be due to the logic that a heading will not scroll into view if it is already in view. However, that simple logic leads to undesirable results when a heading is only partially in view, or very close to being in view. XenForo's floating navbar may also be offsetting the calculation inappropriately. Try resizing the page so that less is visible and before using the TOC and you will see what I mean.

      Also note that Chrome will not scroll the page automatically if you paste a new #section URL while already viewing the same page, due to the section IDs not actually matching; this is a security protection and will not be changed. To get the effect, you need to open an empty tab and try again, or you must click a TOC link. Possibly we can add a workaround for BB-Code links to the same page.
      Reply Reply  
    2. January 30, 2021 5:28 PM
      pegasus pegasus is offline
      VaultWiki Team
      Fixed the following in the next release:

      - Calculation of whether to jump to a heading partially or just outside the viewport.
      - Clicking a TOC link when the browser hash already matches.
      - Clicking a Wiki BB-Code link when the browser hash already matches.
      - Clicking a URL BB-Code link when the browser hash already matches.

      Note: The BB-Code related fixes are still sandboxed. They only apply when the BB-Code being clicked is within the same page-context as the target section; if not, the default browser rules for clicked hash-links still apply (which usually means not jumping to the currently active section). It is rare that this will have an effect, but I can think of a case:
      - A wiki comment, shown beneath the page content, linking to a section in that page content.

      My earlier note about Chrome behavior seems to be incorrect, or was changed in a more recent version of Chrome. Once fixing the other issues, I do not see the alleged effect. It used to be that some browsers did not issue a hard refresh if the URL had a hash and the hash was the only part changed or was not even changed; possibly some browsers still do this. Hard refresh is required to jump VaultWiki sections if the hash is unchanged through address-bar manipulation; VaultWiki does catch address-bar hash changes (onhashchange event).
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 8:40 AM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2025 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2025 DragonByte Technologies Ltd.
    Copyright © 2008 - 2024 VaultWiki Team, Cracked Egg Studios, LLC.