I'm experiencing some incorrect behavior regarding the back button after clicking an anchor. I'm not sure if this is considered a bug because this behavior seems deliberate (after inspecting the source). If it's not a bug, perhaps I'm doing something wrong.
To reproduce:
Visit a page with anchors (for the first time after a hard refresh), this page is currently not in cachedPages.
Visit an anchor on the same page (the page is not cached because !click._validForTurbolinks because link.shouldIgnore because link._anchored)
Click the 'back' button, this pops the url and restored the scroll position (the browser does this and this is the expected behavior)
Turbolinks popstate callback triggers. It does not find the new url in cache and decides to visit it. This triggers a request to the server (unexpected/incorrect) and replaces the page body which resets any expanded/collapsed content etc. (unexpected/incorrect)
My solution for now:
Upgrading to Turbolinks 3 which has cacheCurrentPage() in the public API
Forcing a cacheCurrentPage() on click of the anchor link
Possible solutions in Turbolinks (which may have unintended side effects, but I leave that to you):
Change Turbolinks to abort when popping an anchor on the same page
Change Turbolinks to also cache the current page when clicking an anchor
I'm experiencing some incorrect behavior regarding the back button after clicking an anchor. I'm not sure if this is considered a bug because this behavior seems deliberate (after inspecting the source). If it's not a bug, perhaps I'm doing something wrong.
To reproduce:
!click._validForTurbolinks
becauselink.shouldIgnore
becauselink._anchored
)visit
it. This triggers a request to the server (unexpected/incorrect) and replaces the page body which resets any expanded/collapsed content etc. (unexpected/incorrect)My solution for now:
cacheCurrentPage()
in the public APIcacheCurrentPage()
on click of the anchor linkPossible solutions in Turbolinks (which may have unintended side effects, but I leave that to you):