@tanstack/query-devtools: invalid navigator.language values like "undefined" cause a RangeError at runtime

[jakvbs]

Describe the bug

@tanstack/query-devtools throws at runtime when navigator.language is an invalid string such as "undefined".

The published package still derives the locale from:

(navigator.language || navigator.userLanguage) || "en-US"

If a browser/runtime reports navigator.language === "undefined" instead of undefined, that value reaches locale-sensitive logic and causes a RangeError.

I reproduced this with a minimal React app that mounts ReactQueryDevtools after forcing:

navigator.language = "undefined"
navigator.languages = ["undefined"]
navigator.userLanguage = "undefined"

Your minimal, reproducible example

https://github.com/jakvbs/query-devtools-locale-repro

Steps to reproduce

1. Install the repro dependencies
2. Run the app
3. Open it in Firefox or Chromium
4. The app forces navigator.language to the string "undefined" before mounting ReactQueryDevtools
5. Observe a runtime RangeError

Expected behavior

Devtools should sanitize invalid locale values and fall back safely to "en-US" instead of throwing.

How often does this bug happen?

Every time

Screenshots or Videos

Firefox:

RangeError: invalid language tag: "undefined"
    at mount/dispose< (.../@tanstack_react-query-devtools.js:111:14)

Chromium:

RangeError: Incorrect locale information provided
    at getDefaultLocale (.../chunk-*.js:2496:16)

The wording differs by browser, but the root cause is the same invalid locale path.

Platform

• OS: Linux
• Browsers:
  • Firefox 146.0
  • Chromium (Playwright-installed Chromium)

TanStack Query adapter

react-query

TanStack Query version

Repro app:

• @tanstack/react-query: 5.90.20
• @tanstack/react-query-devtools: 5.91.3

I also inspected published @tanstack/query-devtools tarballs for:

• 5.91.1
• 5.92.0
• 5.93.0

All three still contain:

function getDefaultLocale() {
  let locale = typeof navigator !== "undefined" &&
    (navigator.language || navigator.userLanguage) || "en-US";

TypeScript version

Not relevant for this runtime bug

Additional context

This reproduces in both Firefox and Chromium.

One thing that made this confusing is that a quick search in the current source tree does not obviously show getDefaultLocale, because that logic comes from bundled dependency code in the published @tanstack/query-devtools artifact rather than a handwritten source file in this repo.

The devtools source also has direct locale-sensitive toLocaleString() call sites, so the invalid locale can surface through more than one runtime path.

[eliranamar]

@jakvbs out of curiousity where do you see the usage of getDefaultLocale in the code? i don't see it or navigator.language in a quick search
I want to take a stab at this issue but trying to understand where do you see the code refer to locale formatting.

[jakvbs]

I dug into that a bit more.

You won’t find getDefaultLocale with a quick grep in the TanStack source tree because it does not seem to come from a handwritten file in this repo. packages/query-devtools/src/Devtools.tsx imports DropdownMenu and RadioGroup from @kobalte/core, and the published @tanstack/query-devtools bundle still contains a getDefaultLocale() path reading from:

(navigator.language || navigator.userLanguage) || "en-US"

So this appears to come from bundled dependency code rather than an obvious source file in this repo.

That said, I think this is still worth fixing in @tanstack/query-devtools itself, not only upstream, because devtools also has its own direct locale-sensitive Date.prototype.toLocaleString() call sites in packages/query-devtools/src/Devtools.tsx. So even if part of the issue is coming through bundled @kobalte/core code, sanitizing the locale locally in devtools seems like the safest fix: it makes the package robust regardless of whether the invalid locale reaches Kobalte internals or devtools’ own formatting paths.

[jakvbs]

Following up on this: I opened a PR with a local fix in @tanstack/query-devtools.

PR: #10321

The fix does two things:

• sanitizes invalid browser locale values before devtools uses them for formatting
• wraps the devtools UI in a Kobalte I18nProvider with the sanitized locale

I kept the fix in query-devtools itself rather than relying only on upstream @kobalte/core, because devtools also has its own direct toLocaleString() call sites, so local sanitization makes the package robust regardless of which runtime path sees the invalid locale first.

I also verified the behavior against the repro app with Playwright-managed Chromium and Firefox: the unfixed published packages throw in both browsers, and the patched local packages no longer do.