Open
Description
Link to the code that reproduces this issue
https://codesandbox.io/p/devbox/confident-voice-2xm2wn
To Reproduce
- Go to the code sandbox above
- Run the app
- The key piece of code that triggers this is the Head block that includes a p tag and an html tag:
import Head from "next/head";
export default function Home() {
return (
<Head>
{/* This gets silently dropped */}
<html lang="en" />
{/* This gets left in the body */}
<p>Hello, world</p>
</Head>
);
}
Current vs. Expected behavior
The head manager currently selects a limited set of tags. If there is a tag in Head that won't be selected, the tag is either silently dropped or left in the body.
To prevent developer confusion, there should be a warning that the invalid tag has been dropped rather than just silently swallowing the error.
Provide environment information
This runs in the CodeSandbox above, however I've reproduced it in an app with this next info.
! The local project doesn't define a 'packageManager' field. Corepack will now add one referencing [email protected]+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e.
! For more details about this field, consult the documentation at https://nodejs.org/api/packages.html#packagemanager
"fin@fin: ~/src/next.j" 08:01 14-Mar-25
Operating System:
Platform: linux
Arch: x64
Version: #1 SMP Tue Nov 5 00:21:55 UTC 2024
Available memory (MB): 7547
Available CPU cores: 16
Binaries:
Node: 18.19.0
npm: 9.2.0
Yarn: 1.22.22
pnpm: 9.6.0
Relevant Packages:
next: 15.3.0-canary.8 // Latest available version is detected (15.3.0-canary.8).
eslint-config-next: 15.3.0-canary.8
react: 19.1.0-canary-6aa8254b-20250312
react-dom: 19.1.0-canary-6aa8254b-20250312
typescript: 5.8.2
Next.js Config:
output: N/AWhich area(s) are affected? (Select all that apply)
Pages Router
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)
Additional context
I found this issue debugging #20924. That bug no longer applies, and instead this bug represents the current behavior.