* fix(pages-router): emit console.error for javascript: URL navigation (#1576)
Finishes the Pages Router half of #1576 (the App Router warnings already
land). Adds the four Pages Router scenarios from the upstream
test/e2e/app-dir/javascript-urls suite — Link `href`, Link `as`,
router.push, and router.replace — as e2e fixtures + a Playwright spec, plus
unit coverage for the shared Link shim's dangerous-click handler.
No production change is required: the Link shim already emits the canonical
"Next.js has blocked a javascript: URL as a security precaution."
console.error on click for both `href` and `as`, and the Pages Router
router.push/replace synchronous guard from #1575 already does the same. This
PR adds the missing Pages Router coverage that proves all four scenarios.
Closes#1576
* test(pages-router): suppress dev error overlay before safe navigation
The router.push/replace javascript: scenarios throw synchronously (the
#1575 behaviour that surfaces the console.error), which trips vinext's dev
error overlay. Its backdrop intercepted the follow-up safe-link click,
timing out the test even though the security block already passed. Suppress
the overlay via the existing disableDevErrorOverlay helper after asserting
the block, matching how other pages-router/app-router specs handle
intentional dev-time errors.
* test(pages-router): cover javascript: URL blocking in production build
The Pages Router javascript: URL guard (Link dangerous-click handler in
shims/link.tsx + router.push/replace synchronous guard in shims/router.ts,
both via shims/url-safety.ts) is already correct on main. The existing e2e
spec, however, only runs against the dev server (vp dev), while the Next.js
deploy suite exercises these scenarios against a production build where the
dev error overlay is absent and the client bundle is minified.
Add a pages-router-prod Playwright spec that re-runs all four upstream
scenarios (Link href, Link as, router.push, router.replace) against
vinext build + vinext start, so a prod-only regression is caught here.
Refs #1576
Hoist the `javascript:` / `data:` / `vbscript:` block from inside the
async `performNavigation` body up into `Router.push` / `Router.replace`
themselves so the throw is fully synchronous. Mirrors Next.js's Pages
Router `push`/`replace` at
packages/next/src/shared/lib/router/router.ts:1025-1033,1057-1065.
Why: `performNavigation` is an `async` function, so throwing from inside
it wraps the error in a rejected Promise. `<button onClick={() =>
router.push("javascript:...")}>` does not await that Promise, so React's
event-handler error reporter never observes the throw and the matching
`console.error` is not surfaced through page logs. That is the failure
shape asserted by Next.js's
`test/e2e/app-dir/javascript-urls/javascript-urls.test.ts:341,376`.
Behaviour preserved: navigation is still blocked, and the matching
`console.error("Next.js has blocked a javascript: URL as a security
precaution.")` is still emitted by `assertSafeNavigationUrl`. The inner
guard inside `performNavigation` is kept as defence-in-depth.
Refs #1349
Match Next.js's observable behaviour when `<Link>` clicks, `router.push`,
`router.replace`, and `router.prefetch` block a `javascript:` (or `data:`/
`vbscript:`) URL. Vinext already prevented navigation, but the
`console.error` that Next.js's E2E suite asserts on
(`test/e2e/app-dir/javascript-urls`) was missing because:
- App Router `router.push`/`replace`/`prefetch` threw synchronously
inside `React.startTransition`, so the throw never reached React's
event-handler error reporter.
- `<Link>` rendered an inert anchor with no `href`, so clicking did
nothing — no throw, no log.
- Pages Router `next/router` had no `javascript:` guard at all and
would fall through to `window.location.assign(...)`.
Centralise the matching message in `url-safety.ts` via a new
`reportBlockedDangerousNavigation()` helper. `assertSafeNavigationUrl`
now logs before throwing, and Link's dangerous-click branch and the
Pages Router `performNavigation` both invoke the guard so the throw +
console.error pair mirrors Next.js exactly.
Closes#1349
References:
- packages/next/src/client/components/app-router-instance.ts:345,402,442,460
- packages/next/src/client/components/segment-cache/navigation.ts:537
- packages/next/src/shared/lib/router/router.ts:1025,1057
next/navigation useRouter returned the module-level app router singleton even when no AppRouterContext provider was mounted. That masked components rendered outside the App Router boundary, diverging from Next.js and hiding integration bugs.
The shim now reads the mounted AppRouterContext and throws the Next.js invariant when it is absent. The App Router browser and SSR roots provide the existing appRouterInstance so legitimate app renders keep the same public router surface.
* fix(app-router): block javascript: URLs in router.push/replace/prefetch
router.push("javascript:alert(1)") currently runs the script. _appRouter.push,
.replace, and .prefetch in shims/navigation.ts forward the href straight to
navigateClientSide, where isExternalUrl matches the javascript: scheme and
falls through to window.location.assign, which executes the URL. router-derived
hrefs (URL params, user content, query state) become an XSS vector.
Next.js blocks dangerous URI schemes at the router boundary and throws
"Next.js has blocked a javascript: URL as a security precaution." See
packages/next/src/client/components/app-router-instance.ts:343,400,440,458 in
the canary tree. Vinext's url-safety.isDangerousScheme already covers
javascript:/data:/vbscript: with the same obfuscation handling Next.js uses,
and Link and Form already gate on it; the App Router programmatic surface was
the remaining gap.
Add assertSafeNavigationHref at the top of push/replace/prefetch, before the
isServer short-circuit so SSR callers fail loudly too. Throw an Error with
the verbatim Next.js message so consumer error tooling can match across both
frameworks.
Test: tests/router-javascript-urls.test.ts ports the assertions from
.nextjs-ref/test/e2e/app-dir/javascript-urls/javascript-urls.test.ts down to
unit scope, covering javascript:/data:/vbscript:, uppercase, embedded tabs,
leading whitespace, and a safe-URL no-throw guard for each method.
* test(router): split ported vs vinext-only dangerous-scheme cases
The header said "Ported from Next.js" but data: and vbscript: are vinext
extensions, not in the upstream e2e suite. Add a Coverage split note that
attributes each scheme: javascript: + obfuscation variants come from
test/e2e/app-dir/javascript-urls/javascript-urls.test.ts; data: and vbscript:
ride on top via shims/url-safety.isDangerousScheme.
* fix app router dangerous redirect gaps
* test address dangerous URL review nits
James Anderson