Home
Projects
Blog
Toggle Cursor trail
LinkedIn
GitHub
Printables
Email Me
Switch to dark theme

Application error: a client-side exception has occurred while loading localhost

First Published: 2025-06-04

Last Updated: 2025-06-20

Documenting a server-side bug which occured when migrating from Next.js 15.1.x

TLDR

The Windows server sent a UTF-8 encoded file with CP-1252 encoding instead.

Background

This occured when I was developing Subtext.
Subtext uses a custom Python FastAPI setup for hosting the Frontend which is a static Next.js site.
Until this bug I hadn't had any issues with this setup.

The Bug

When I was updating Subtext, I wanted to bump the Next.js version, if only to stop the annoying dependabot CVE-2025-29927 warnings.
So I did, and nothing went wrong, and everything worked perfectly in dev.
Then I sent it to the build server and the bug happened: every build would build without issues.
But when running the builds, I would get this error: Application error: a client-side exception has occurred while loading localhost (see the browser console for more information).
and there would be three errors in the console

No group found for id "«Rufb»"
No group found for id "«Rfb»"
Uncaught Error: No group found for id "«Rufb»"

Debugging

When I searched Google, very fortunately the first result was relevant.
It revealed that this issue had occured before in the react-resizable-panels package before.
Since I was using react-resizable-panels through the ShadCN Resizable element, through some testing, I was able to isolate this bug to some interaction with the Resizable component.

I then made a barebones create-next-app application, with only a ShadCN Resizable component and was able to recreate the issue when the application was exported and hosted via my backend.
Since this only occured when the application was exported and hosted and not in dev, I spun up a NGINX vm for debugging with the exact same build that was causing issues.
I had expected to encounter the exact same bug again, but it worked flawlessly.

This meant that it was my FastAPI backend which caused this error.
I first compared the FastAPI and NGINX requests against the same file in the network tab, and there were no obvious differences, no file fetches failed and each file fetched was the same size.
I then spun up a script which queried the same file from both servers and diffed them.
This script then flagged index.html which showed that NGINX returned

data-panel-id="«R6fb»"
while FastAPI returned
data-panel-group-id="«Rfb»"

Conclusion

Eventually, I found the root cause of the bug:
return HTMLResponse(open(static_file_path, "r").read())
And the fix:
return HTMLResponse(open(static_file_path, "r", encoding="utf-8").read())

Explanation: In open(), if encoding is not set to anything, by default Python will use the default system encoding:locale.getencoding()
On Windows, this returns CP-1252. When Python opened and read the UTF-8 file using CP-1252, it stripped the  character from data-panel-id which broke the application as React could no longer find the element.

The upgrade to Next.js 15.2.x or 15.3.x is what triggered the bug as previously in 15.1.x, the exported html had a data-panel-group-id of :R2ftb:.

Note: If anyone finds it useful, they can find the testing repo here: https://github.com/jchu634/next-export-test

This work is licensed under

CC BY 4.0

Creative Commons IconCreative Commons BY Icon
Profile Picture
linkedIn Profile LinkGitHub