-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
[Bug]: useBlocker fails when blocking function is quick to proceed #11613
Comments
So if I understand it correctly, the first "oops, let's go back" navigation is fine because that is a reaction to a popstate event but then you would need to wait for the popstate event for that navigation before redoing the original navigation |
I haven't tested the fix, but came across this after noticing an issue where a simple Both of the following reproduce the issue: useEffect(() => {
if (blocker.state === "blocked") {
if (window.confirm(unsavedMessage)) {
console.log("User wants to leave");
// setTimeout(() => {
blocker.proceed();
// }, 0);
} else {
console.log("User wants to stay");
blocker.reset();
}
}
console.log(blocker.state);
}, [blocker]); useEffect(() => {
if (blocker.state === "blocked") {
blocker.proceed();
}
console.log(blocker.state);
}, [blocker]); This seems to be confirmed by the fact that the This also seems to be discussed in discussion item #10489. |
Resolved by #11930 and will be include din the next release 👍 |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
What version of React Router are you using?
6.23.1
Steps to Reproduce
Take the example from https://github.com/remix-run/react-router/blob/main/examples/navigation-blocking/src/app.tsx
and remove the user input based confirmation and replace it with an immediate confirmation, e.g. something like
Full code in https://stackblitz.com/edit/github-qwtgqt
Expected Behavior
When you go to view "One", then to the form view, enter "123" in the field and press back in the browser, you should end up on the "One" view as the blocker allows proceeding.
Actual Behavior
You remain on the form view (this might be dependent on the machine and the browser, tested with Chrome on a M1 mac). In another test case where the proceed function call takes a very short time, the back navigation succeeds around 80% of the time.
I think this is because the blocker functionality that in this case immediately after the user's back navigation will navigate forward and then back again. This does not work because
history.go
is asynchronous and you are supposed to wait for apopstate
before calling it again: https://developer.mozilla.org/en-US/docs/Web/API/History/goSimilarly, if you do something like this in JS
You will only see two popstate events, and for paths 4 and 3.
If you use short delay instead, like
you see the expected three events and actually end up on the correct history entry
The text was updated successfully, but these errors were encountered: