Search for a command to run...
A bug that only happens for some users, that you can never reproduce, that isn't in your code. Welcome to the React + browser-translation crash — what causes it, why it's so sneaky, and the battle-tested one-file fix.
Exploring the new tools and techniques on frontend development. Loves to meet up with new people and participate in the community. I do interesting stuff on codepen https://codepen.io/nirazanbasnet
No comments yet. Be the first to comment.
A few months ago, my product manager dropped something in the team channel. "We are adding an AI agent to the platform next quarter. It will handle follow-ups automatically." Just like that. One messa
f you’re diving into React, you’ve likely come across the useRef hook. But what exactly is useRef(), and how can it make your life easier? In this post we’ll cover what useRef is, walk through five
Upgrading a core production database is usually the stuff of dev nightmares. It often involves maintenance windows, scheduled downtime, and the looming fear of a botched migration. But what if you cou
We are moving into products that adapt, predict and react with real context. Designing only interfaces is not enough anymore. We are designing experiences that understand the user. Designers and digital agencies are now challenged to move beyond trad...
Engineering at JoBins
167 posts
Welcome to Engineering at JoBins — where we share the stories, insights, and lessons from building a world-class hiring platform. From system design and scalability to developer tools and team culture, our engineers write about the real challenges we solve every day. Whether you're a curious developer or a fellow builder, we hope our experiences inspire and inform your own engineering journey.
There's a special kind of bug that makes you question your career.
It's the bug you cannot reproduce. QA can't reproduce it. The user swears the app "just goes blank" or "freezes and everything disappears." Your error tracker shows a stack trace deep inside React with a message you've never seen. You stare at your code. Your code is fine. You didn't even touch the file in the stack trace this sprint.
Then, three days later, someone on the call casually says: "Oh, I have Chrome set to auto-translate the page to English."
And everything clicks.
If your app has ever mysteriously white-screened for a subset of users — especially international users, or anyone whose browser offers to translate your page — this post is for you. Let's talk about the collision between React and in-browser translation, why it's nobody's "bug" exactly, and how to fix it for good.
Here's the crash, in its natural habitat:
NotFoundError: Failed to execute 'insertBefore' on 'Node':
The node before which the new node is to be inserted is not a child of this node.
Or its equally charming sibling:
NotFoundError: Failed to execute 'removeChild' on 'Node':
The node to be removed is not a child of this node.
In plain English, the browser is saying:
"You told me to put this new element right before that other element. But that other element isn't actually inside the container you gave me. So... no."
React asked the DOM to do something, and the DOM refused because reality no longer matched React's mental model. React has no fallback for this. It throws, the error bubbles up, and your whole component tree unmounts into an error boundary (or a blank page if you don't have one).
The million-dollar question: who moved the furniture?
Imagine two roommates who both like to rearrange furniture, and neither tells the other.
React is a very particular roommate. It keeps a detailed floor plan in its head (its internal "fiber tree") of exactly where every chair and lamp is. When it wants to make a change, it doesn't look around the room first — it trusts its floor plan. "The lamp is next to the couch, so I'll put the new plant right before the lamp."
Google Translate is the other roommate. It walks in, grabs every piece of text in the room, and wraps each one in a new box to translate it. In doing so, it quietly moves things around — the lamp is now inside a box, in a slightly different spot.
React, still trusting its old floor plan, reaches for where the lamp used to be... and grabs air. Crash.
Neither roommate is doing anything "wrong." React is fast because it trusts its floor plan instead of re-checking the room on every operation. Google Translate has to rewrite text nodes to translate them — that's literally its job. They just can't both own the DOM at the same time.
This is the part most people never see. Let's make it concrete.
You render something innocent like this:
<p>Hello, welcome back!</p>
Which produces this DOM:
<p>
"Hello, welcome back!" <!-- a single text node -->
</p>
Now Google Translate kicks in. To translate that sentence, it can't just edit the text node in place — it splits and wraps the text in <font> elements:
<p>
<font style="vertical-align: inherit;">
<font style="vertical-align: inherit;">こんにちは、おかえりなさい！</font>
</font>
</p>
See what happened? The original text node that React was tracking is gone. In its place is a <font> wrapper (or several) that React never created and doesn't know about.
As long as nothing changes, everyone's happy — the translated text just sits there. The trouble starts on the next update.
This is the key insight that makes the bug so maddening.
Translation happens after your page loads. So the initial render is fine. The app looks great. Translated, even. Everyone's happy.
Then something dynamic happens:
A chat message streams in token by token.
A loading spinner swaps out for real content.
A toast notification appears and disappears.
An animation library like Framer Motion mounts/unmounts an element via <AnimatePresence>.
A conditional {isOpen && <Modal />} flips.
Any of these makes React perform a insertBefore or removeChild against a node whose neighborhood was silently rewritten by the translator. Boom.
That's why static marketing pages seem immune and rich, interactive apps (dashboards, chat, feeds) get wrecked. The more your UI updates, the more chances for the collision. And because it depends on:
the user having translation on, and
a specific DOM update happening on already-translated content,
...it's nearly impossible to reproduce on demand. Classic heisenbug.
It's not only Google Translate, by the way. Any tool that mutates your DOM from the outside can trigger the same class of crash — the Microsoft Edge translator, some browser extensions, older Grammarly integrations, and so on. Translation is just by far the most common trigger.
I'll make this concrete, because a real story lands better than a hypothetical.
We ship a product whose default language is Japanese. Most of our users read Japanese happily — but a meaningful chunk browse with Chrome set to auto-translate the page into English, Nepali, Hindi, whatever their preference is. Perfectly reasonable. That's the browser doing its job.
The surface that kept crashing was a streaming AI chat — assistant messages arrive token by token, and the message list animates in and out with Framer Motion's <AnimatePresence>. In other words, the single most update-heavy corner of the whole app: constant insertBefore/removeChild churn, on content the translator had already rewritten. It was a perfect storm.
For weeks it showed up in our error tracker as a NotFoundError deep inside React's commit phase, with a component stack pointing at chat components nobody had touched. Unreproducible in the office. Then someone turned on auto-translate to check the Japanese copy in English... and watched it die on the first streamed reply. The guard below is what we shipped, and the crashes went to zero while translation kept working.
Credit where it's due: the core technique isn't something I invented — it's the community-vetted mitigation from the long-running facebook/react#11538 thread, refined by a lot of people who hit this before us. This post is me explaining why it works and how to apply it well.
Here's the good news: there's a well-known, battle-tested fix, and it's small.
The idea: React only ever passes valid nodes to insertBefore/removeChild during normal operation. The only time it passes a node whose parent has secretly changed is when something external mutated the DOM. So we can safely make those two methods a little more forgiving — if the target node isn't where it's supposed to be, degrade gracefully instead of throwing.
This is the accepted community mitigation, discussed at length in facebook/react#11538.
// translate-crash-guard.js
export function installTranslateCrashGuard() {
// Server-safe: do nothing during SSR / if the DOM isn't available.
if (typeof window === "undefined" || typeof Node !== "function" || !Node.prototype) {
return;
}
// Install exactly once, even across hot reloads / double invocation.
if (window.__translateCrashGuardInstalled) return;
window.__translateCrashGuardInstalled = true;
const originalRemoveChild = Node.prototype.removeChild;
Node.prototype.removeChild = function (child) {
if (child.parentNode !== this) {
// A translator already moved this node out from under `this`.
// React's intent was to delete it, so remove it from wherever it
// actually lives now — but never throw.
if (child.parentNode) child.parentNode.removeChild(child);
return child;
}
return originalRemoveChild.call(this, child);
};
const originalInsertBefore = Node.prototype.insertBefore;
Node.prototype.insertBefore = function (newNode, referenceNode) {
if (referenceNode && referenceNode.parentNode !== this) {
// The reference node was re-parented by a translator. Appending keeps
// the new node visible in the right container instead of throwing.
return originalInsertBefore.call(this, newNode, null);
}
return originalInsertBefore.call(this, newNode, referenceNode);
};
}
Let's read it slowly, because monkey-patching a native prototype sounds scary and I want you to trust it:
removeChild: React says "remove child from this." We check: is child actually inside this? If yes → do exactly what the browser always did. If no (a translator moved it) → quietly remove it from its real parent and return, instead of throwing. React wanted it gone; it's gone.
insertBefore: React says "insert newNode right before referenceNode inside this." We check: is referenceNode actually inside this? If yes → normal behavior. If no → we can't honor the exact position (the anchor moved), so we append newNode to this instead. The new content still shows up, just possibly one slot off inside a subtree the translator already reshuffled.
The crucial property: for correct React operations, nothing changes. The child.parentNode !== this check is false in the normal case, so you fall straight through to the original method. The new branches only run when the DOM was already mutated behind React's back. You're not slowing anything down or changing healthy behavior — you're adding a safety net that's invisible until the exact moment you need it.
Install it as early as possible on the client — before your app does its first dynamic update. Once at startup is enough.
Next.js (App Router): run it at module scope in a client component that's high in the tree, e.g. your providers file:
"use client";
import { installTranslateCrashGuard } from "@/lib/translate-crash-guard";
// Runs when this client module loads, during hydration. No-ops on the server.
installTranslateCrashGuard();
export default function Providers({ children }) {
return <>{children}</>;
}
Vite / Create React App: call it before you mount React.
// main.jsx / index.jsx
import { installTranslateCrashGuard } from "./translate-crash-guard";
installTranslateCrashGuard();
ReactDOM.createRoot(document.getElementById("root")).render(<App />);
That's really it. One tiny module, one call.
You don't need a real browser extension to test this. Just simulate what a translator does — re-parent a node — and assert the DOM ops no longer explode.
import { describe, it, expect, beforeAll } from "vitest";
import { installTranslateCrashGuard } from "./translate-crash-guard";
describe("translate crash guard", () => {
beforeAll(() => installTranslateCrashGuard());
it("doesn't throw when the reference node was re-parented", () => {
const container = document.createElement("div");
const elsewhere = document.createElement("div");
const ref = document.createElement("span");
elsewhere.appendChild(ref); // ref now lives somewhere else — like after translation
const node = document.createElement("b");
expect(() => container.insertBefore(node, ref)).not.toThrow();
expect(node.parentNode).toBe(container); // still ends up in the right place
});
it("still behaves normally for valid operations", () => {
const container = document.createElement("div");
const a = document.createElement("a");
const b = document.createElement("b");
container.appendChild(b);
container.insertBefore(a, b);
expect(container.firstChild).toBe(a); // normal behavior preserved
});
});
Green tests, and now you've got a regression guard so nobody "cleans up" the patch six months from now and reintroduces the crash.
The patch stops the crash. But there's a bit more nuance to doing this well.
It's tempting to slap translate="no" on <body> and call it a day. Please don't. Translation is an accessibility and inclusion feature. For a huge number of people, auto-translate is the difference between using your product and bouncing. Killing it globally "fixes" the crash by breaking the experience for the exact users who needed help most. The whole point of the patch above is that you get to keep translation working.
translate="no" selectively, for things that must never be translatedSome content genuinely shouldn't be translated, because translating it changes its meaning or breaks it:
<code translate="no">git rebase --onto main</code>
<span translate="no">API_KEY_9f3c...</span>
<span class="notranslate">YourBrandName</span>
Good candidates: code snippets, API keys/tokens, precise identifiers, brand names, and any string a user might copy-paste verbatim. This also reduces how much of your DOM gets rewritten, which reduces collision surface as a nice side effect.
lang attribute honestly<html lang="ja">
Tell the browser what language your content is actually in. It makes translation decisions saner and improves accessibility for screen readers too. If you render mixed-language content, mark the exceptions: <span lang="en">...</span>.
This is a lighter, complementary mitigation. Bare text nodes that sit as siblings of elements are the most fragile:
{/* fragile: raw text node next to an element */}
<div>
{count} items
{isOpen && <Menu />}
</div>
{/* sturdier: text lives inside its own element */}
<div>
<span>{count} items</span>
{isOpen && <Menu />}
</div>
Wrapping gives the translator an element boundary to work with, which reduces (but does not fully eliminate) the collisions. Think of it as defense in depth, not a replacement for the guard.
The patch should:
run only in the browser (typeof window !== "undefined"),
install a single time (a flag on window),
and touch only insertBefore and removeChild.
Resist the urge to patch every DOM method "just in case." These two are where React's reconciler actually collides with translation. More surface area = more risk, less clarity.
Even with the guard, wrap your app in a React error boundary. It's good hygiene for a dozen other reasons, and it means that if anything slips through, users get a friendly "something went wrong, reload" instead of a blank void.
Fair instinct. As a general rule, yes — reaching into Node.prototype is the kind of thing that should make you pause.
But this is one of the rare, well-justified exceptions:
It's surgical: two methods, with a fast-path that's identical to the original for all valid calls.
It's behavior-preserving: it only diverges when the DOM was already corrupted by an external actor, i.e. when the original method would have thrown anyway.
It's the accepted fix: it's been discussed, refined, and deployed in production React apps for years, straight out of the official issue thread.
The alternative is shipping a known crash to a meaningful slice of your users.
Weigh it honestly: a tiny, well-documented, well-tested patch versus a white screen for translated users. This is a case where the pragmatic call is the correct one.
I'm not going to oversell this. The guard is a crash preventer, not a translation perfecter.
Under heavy translation, a node might occasionally render one slot out of place inside an already-reshuffled subtree. It won't crash; it might look slightly off for a beat until the next clean render.
It doesn't make React and translation "aware" of each other — nothing short of the browser vendors and framework authors agreeing on a contract would. It just stops them from killing your app when they disagree.
For the overwhelming majority of apps, that trade — "occasionally slightly imperfect" instead of "occasionally completely dead" — is an easy yes.
Symptom: Your React app white-screens for some users with NotFoundError: Failed to execute 'insertBefore' / 'removeChild'. You can't reproduce it.
Cause: In-browser translation (Google Translate, etc.) rewrites text nodes into <font> wrappers, re-parenting nodes React still tracks. On the next update, React's insertBefore/removeChild hit the wrong parent and the DOM throws.
Fix: Install a tiny guard that makes those two Node methods tolerant of externally-moved nodes — degrade gracefully instead of throwing. Behavior-preserving for all normal operations.
Best practices: keep translation on (it's accessibility), use translate="no" only for code/tokens/brand names, set lang honestly, wrap bare dynamic text, install the guard once, browser-only, and keep an error boundary around your app.
Your users who read in a different language than your default? They'll never know how close they came to a blank screen. That's the goal.
If this saved you a debugging afternoon, drop a ❤️ or a 🦄 — and tell me in the comments which dynamic feature was crashing for you. Streaming chat is my personal nemesis.