-
Notifications
You must be signed in to change notification settings - Fork 27k
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
hashChangeStart does not fire anymore #26853
Labels
bug
Issue was opened via the bug report template.
Comments
It does appear to not fire the events when i18n is enabled. Probably due to |
10 tasks
kodiakhq bot
pushed a commit
that referenced
this issue
Jul 7, 2021
My last PR (#26205) made the hash change events not fire when in i18n was enabled, as seen in #26853. This PR fixes that and adds a test for this case. fixes #26853 ## Bug - [x] Related issues linked using `fixes #number` - [x] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes
flybayer
pushed a commit
to blitz-js/next.js
that referenced
this issue
Aug 19, 2021
My last PR (vercel#26205) made the hash change events not fire when in i18n was enabled, as seen in vercel#26853. This PR fixes that and adds a test for this case. fixes vercel#26853 ## Bug - [x] Related issues linked using `fixes #number` - [x] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Next.js are you using?
11.0.2-canary.4
What version of Node.js are you using?
12.0.0
What browser are you using?
Chrome, Firefox, Safari
What operating system are you using?
macOS
How are you deploying your application?
next start, Vercel
Describe the Bug
Listening to the routers hashChangeStart event worked in 11.0.1 to initiate smooth-scrolling behavior.
I noticed in initial tests of the latest Canary version that this event is no longer triggered.
Expected Behavior
Fire hashChangeStart when the hash changes
To Reproduce
Local tests show that this problem exists since version 11.0.2-canary.0.
The hashChangeStart event gets not used too often in the project; I looked at the latest changes.
The following commit got merged a couple of days ago, part of canary.0, which causes the problem.
be62f02
I guess that the condition is somehow too specific, blocking from entering.
next.js/packages/next/next-server/lib/router/router.ts
Lines 936 to 940 in be62f02
The text was updated successfully, but these errors were encountered: