Turbo Drive breaks skip links about turbo HOT 5 CLOSED

We are also having a problem with Turbo on anchor links and I believe related to this issue as well.

Say we have two pages with routes, /page-a and /page-b. And page A has an anchor link /page-a/#anchor. If on page A we click on the link that navigates to #anchor, page A is refetched, page scrolls to top and then scrolls to anchor which is quite unexpected.

If I disable default behaviour on the anchor link trigger with e.preventDefault() then we have another problem with history.

1. Go to page A and click the link that points to the anchor link.
2. Page scrolls to the anchor point and URL updates as /page-a/#anchor.
3. Navigate to Page B. Page B loads and url is updated as /page-b.
4. Now click history back button of the browser. Url updates as /page-a/#anchor but navigation fails. We stay at page B.

I guess a method mentioned above pushHistoryWithLocationAndRestorationIdentifier would solve our problem for the second scenario.

Or #125 should fix our issue I believe.

Is there any workaround until a fix is released?

from turbo.

I tested skip-link branch with our app and it fixes the problem I described above with one exception. We do not use caching as it seems to introduce various issues for our app that uses Vue.js heavily. So the problem is, when caching is disabled, navigation between anchors on the same page using history buttons, results in refetching the page thus introducing scroll to top then to anchor issue.

For example:

1. Go to /page-a. Click /page-a/#anchor-1, then click /page-a/#anchor-2.
2. Click browser history back then forward buttons.

On each restoration visit to anchors on the same page, page is refetched, browser scrolls to top, then scrolls to the anchor point.

I'm happy to open a new issue, if you think this should be handled separately.

Edit: Just sent a PR fixing this problem.

from turbo.

@cwgw I've opened #57 to add test coverage to ensure the correct behavior, but I'm unable to reproduce the issue.

Could you comment on that PR to help me craft the correct HTML and test coverage to fail the test?

EDIT: I commented too soon, I was able to get a failing test, but could still use some guidance on whether or not it faithfully reproduces the scenario detailed within this issue.

from turbo.

@seanpdoyle Thanks for your response. I'm happy to assist with test coverage.

Just to clarify a bit: The issue is not with window location or scroll position but with focus navigation. The html spec says that…

User agents are required to set the sequential focus navigation starting point to the target element when navigating to a fragment.

…and this is the normal behavior that Turbo Drive is preventing. Currently, after navigating to a fragment, the sequential focus navigation starting point is set to the top of page, rendering the skip link useless.

To cover this in a test, you'd need to:

1. trigger a click on the skip link
2. trigger a tab keypress
3. assert that the correct element receives focus (which should be the first focusable element within or after the target element)

from turbo.

After some more investigation, I'm seeing unique behavior in Chrome. In Firefox and Safari the issue is present as I've described it above.

In Chrome, the focus navigation is set correctly after using the skip link once. However, the issue presents after using the skip link additional times.

FWIW I'm running:

• [email protected]
• [email protected]
• [email protected]
• [email protected]

from turbo.