next.js: Tab freeze when updating layout.tsx file
Verify canary release
- I verified that the issue exists in the latest Next.js canary release
Provide environment information
Operating System:
Platform: linux
Arch: x64
Version: #1 SMP Wed Mar 2 00:30:59 UTC 2022
Binaries:
Node: 18.0.0
npm: 8.6.0
Yarn: 1.22.18
pnpm: N/A
Relevant packages:
next: 13.4.4
eslint-config-next: 13.4.4
react: 18.2.0
react-dom: 18.2.0
typescript: 5.1.3
Which area(s) of Next.js are affected? (leave empty if unsure)
App directory (appDir: true), CLI (create-next-app), Turbopack (–turbo)
Link to the code that reproduces this issue or a replay of the bug
https://github.com/castrix/nextjs-hmr-bug
To Reproduce
- run the dev server
npm run dev
-
navigate the route to localhost:3000/home
-
switch to the editor, modify layout file in
/app/home/layout -
switch to the browser, you can see that the tab freeze
Describe the Bug
When updating layout file while the dev server is running, the tab freeze, the HMR stuck, tab CPU high 50-100%, the page not reloading.
- This happen in regular
next devscript and innext dev --turboflag.
Expected Behavior
Page reload, tab not freezing
Which browser are you using? (if relevant)
Chrome 114.0.5735.91
How are you deploying your application? (if relevant)
No response
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 3
- Comments: 20 (7 by maintainers)
Hey man, the issue in this case is that by adding content to the layout in combination with running it as a client component you’re getting a hydration error which doesn’t seem to be handled all that well on nested layouts. (You can test this by changing the root layout.
Right now, if you have a nested layout that uses “use client” instead of a hydration error your whole tab locks up.
Sorry for the ping @leerob just curious if this is a known issue internally already. 👍
@castrix Nope, I’m just fetching global data (header, footer, ecc) in the root layout and revalidating every 10s; I will try latest canary, thanks!
Chrome 114.0.5735.91
Edge 114.0.1823.37
Firefox 114.0
Hi @JesseKoldewijn, I’m not sure why but I wasn’t able to configure the correct docker for it, but I’ve updated the repro repo with Canary and also tested it on chrome, edge, firefox, and the issue still happens.
Here I added the attachment to show you the issue:
I tried on latest canary and latest stable, both behaving the same.
I used latest stable in repro repo because I first found the issue on latest canary and switched back to the latest stable to see if it will work, but it still happen.
Hi, thanks for looking at it.
I ran it on wsl2, I’ll try to dockerize it later and let you know if it’s still happening