Open
Description
Link to the code that reproduces this issue
https://github.com/HuriHuchi/next-issue-report
To Reproduce
- Start the application in dev (
npm run dev) - Define a Root Layout(
app/layout.tsx) with and inline script to initializewindow.__ENV
export default function RootLayout({ children }) {
return (
<html lang="en">
<head>
<script
dangerouslySetInnerHTML={{
__html: `window.__ENV = { "API_KEY": "test", "ENV": "development" };`,
}}
/>
</head>
<body>{children}</body>
</html>
);
}- Add an
app/error.tsxfile to handle errors at the root level
"use client";
export default function Error({ error, reset }) {
return (
<div>
<h1>Error: {error.message}</h1>
<button onClick={reset}>Try again</button>
</div>
);
}- Create a server component page (app/error/page.tsx) that throws an error.
export default function ErrorPage() {
throw new Error("Test error");
return <div>Error Page</div>;
}- Visit the /error route in the browser
- Check the rendered HTML source and browser console for
window.__ENV
Current vs. Expected behavior
Expected Behavior
- With
app/error.tsxpresent, the Root Layout (app/layout.tsx) should remain intact, and its scripts (e.g., the inline script initializing window.__ENV) should execute, making window.__ENV available in the browser (e.g., console.log(window.__ENV) outputs { API_KEY: "test", ENV: "development" }). - The error should be caught by
app/error.tsx, preventing propagation to the global error boundary, and the Root Layout’s structure should be preserved.
Actual Behavior
- The browser receives an HTML response with , indicating an unexpected fallback to a global error-like state, despite
app/error.tsxbeing defined. - The inline script from the Root Layout appears in the :
<script dangerouslySetInnerHTML={{__html: "window.__ENV = {\"API_KEY\": \"test\", \"ENV\": \"development\"};"}}></script>- However,
window.__ENVis not initialized (console.log(window.__ENV)returnsundefined).
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:24 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6030
Available memory (MB): 36864
Available CPU cores: 12
Binaries:
Node: 20.14.0
npm: 10.8.2
Yarn: 1.22.22
pnpm: N/A
Relevant Packages:
next: 15.2.0-canary.66 // Latest available version is detected (15.2.0-canary.66).
eslint-config-next: N/A
react: 19.0.0
react-dom: 19.0.0
typescript: 5.7.3
Next.js Config:
output: N/AWhich area(s) are affected? (Select all that apply)
Not sure
Which stage(s) are affected? (Select all that apply)
next dev (local)
Additional context
- The presence of app/error.tsx should catch the error at the root level and render its content within the Root Layout. However, the rendered HTML suggests that the Root Layout is bypassed or not fully applied, and the structure takes over.
- Replacing the inline script with an external <script src="/__ENV.js"> yields the same result: the script is included but does not execute.
- The issue persists even when no app/global-error.js is defined, indicating that this is not strictly a global error boundary problem but potentially a bug in how server component errors interact with the Root Layout and error handling.
Why is this happening? Is this intended behavior?