-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Canceling turbo:click
does not stop a frame navigation.
#610
Comments
this was solved by #729 |
This was reintroduced by #744 @seanpdoyle any reason why the test about this issue was removed? https://github.com/hotwired/turbo/pull/744/files#diff-ba1c7f863678da4856a147f82730481b725f848e033969fe679fc27f1e3263b4L459-L465 |
@manuelpuyol that test was introduced between the last stable release, but complicated the process of rolling back the With the rollback released, I'm in favor of re-introducing the test coverage and corresponding behavior, if we can! |
@seanpdoyle cool, I can try looking into it... One question though, why do we always prevent turbo/src/core/frames/link_interceptor.ts Line 42 in 22fd88a
|
That is a decision that pre-dates my involvement in the project: https://github.com/hotwired/turbo/blame/v7.0.0-beta.1/src/core/frames/link_interceptor.ts#L39-L40 I'm in favor of experimenting with a different implementation, and support some trial and error with the hopes that the test suite will guide us! |
before-visit events, that are caused by promoted frame links, are also not cancellable.
|
Looking at the
turbo:click
docs:Though if your link triggers a frame navigation, running
preventDefault()
doesn't cancel it.document.addEventListener('turbo:click', (e) => e.preventDefault())
on a Visit:Screen.Recording.2022-06-23.at.4.25.54.PM.mov
document.addEventListener('turbo:click', (e) => e.preventDefault())
on a frame:Screen.Recording.2022-06-23.at.4.26.51.PM.mov
The text was updated successfully, but these errors were encountered: