nextjs - 💡(How to fix) Fix Bug: Scripts disabled due to cache error when navigating back via browser history (Regression) Next JS 16.2.6

Link to the code that reproduces this issue

https://github.com/barisdemirr/nextjs-16.2.6-bug-report

To Reproduce

1. Start the development server (npm run dev).
2. Open the application in any browser (Chrome, Edge, etc.).
3. Navigate from the initial page to any other route using client-side navigation.
4. Click the browser's "Back" button to return to the previous page.
5. Try interacting with any element that requires JavaScript (or check if initial scripts run).
6. Observe that scripts are not executing and no errors are logged in the console.

Current vs. Expected behavior

When navigating back via the browser history, the page should restore correctly, and all client-side scripts should execute and remain functional without silent failures.

Provide environment information

- OS: Windows 10 Pro
- Browser: Tested on multiple browsers (Chrome, Edge, etc.)
- Next.js version: 16.2.6
- Node.js version: v24.11.1
- React version: 19.2.4

Which area(s) are affected? (Select all that apply)

cacheComponents, Script (next/script), Route Handlers

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local)

Additional context

This issue was highly frustrating to debug because of the absolute lack of error logs, warnings, or stack traces in the browser console. The page visually restores itself from the cache perfectly, but all JavaScript execution completely freezes up and client-side interactions become totally unresponsive only after using the browser's "Back" button.

I tested this behavior thoroughly across multiple browsers (including Chrome and Edge) on Windows 10 Pro, and the result is entirely consistent. It acts as a major blocker for daily local development since history navigation is a frequent part of the workflow.

The issue only triggered immediately after upgrading to Next.js v16.2.6. Rolling back to the previous working version instantly resolved the issue, which strongly indicates a regression within the router's client-side caching mechanism or bfcache handling in this specific release.