Skip to content

fix: Fixed the "NaN" --pref value being coerced to a number - #3925

Open
NUAAwqy wants to merge 1 commit into
mozilla:masterfrom
NUAAwqy:fix-pref-nan-coercion
Open

NUAAwqy wants to merge 1 commit into
mozilla:masterfrom
NUAAwqy:fix-pref-nan-coercion

Conversation

@NUAAwqy

@NUAAwqy NUAAwqy commented Nov 3, 2026

Copy link
Copy Markdown

Problem

coerceCLICustomPreference() decides whether a --pref name=value value is numeric with:

if (value === `${parseInt(value)}`) {
  value = parseInt(value, 10);
}

parseInt('NaN') is NaN, and `${NaN}` is the string "NaN", so the literal value NaN passes the round-trip check and becomes the number NaN.

Downstream, firefox-profile's setPreference() quotes only true, false and string values and falls back to parseInt(value, 10).toString() for everything else. That means the number NaN ends up in prefs.js as an unquoted token, while the string "NaN" — what every other non-numeric value gets — is quoted:

--pref some.pref=... written to prefs.js before this change after
455 user_pref("some.pref", 455); unchanged
NaN user_pref("some.pref", NaN); user_pref("some.pref", "NaN");
Infinity user_pref("some.pref", "Infinity"); unchanged

Both lines above were produced by calling firefox-profile's own setPreference(), so this is not a hypothetical serialization. NaN is not a representable preference value, and configureThisProfile() also logs the custom preferences with JSON.stringify(), which renders it as null — so web-ext run --pref some.pref=NaN reports and writes something other than what was asked for.

Fix

Only accept the round-trip when parseInt() actually produced a number. Everything else keeps its current behaviour, including the documented "floats stay strings" case (4.55 is still written as "4.55").

Tests

Added two regression tests to tests/unit/test-firefox/test.preferences.js: one for the NaN value itself, and one pinning the neighbouring non-numeric forms (Infinity, 0x1f, 1e3) that the changed condition touches.

  • Before the fix: 12 passing, 1 failing — AssertionError: expected NaN to be a string.
  • After the fix: 13 passing.
  • npm run build && npm test (eslint plus the whole unit suite): 591 passing, no failures.
  • prettier --list-different reports no difference for both changed files.

Notes

I did not find an existing issue for this, so there is no Fixes #… in the description; say the word and I'll open one and link it.

This investigation was AI-assisted (Qoder Desktop); I verified each claim above against the source in src/firefox/preferences.js and against the installed firefox-profile implementation.

coerceCLICustomPreference() treated a value as numeric when it equalled
`${parseInt(value)}`, and `${NaN}` is the string "NaN". That turned
`--pref some.pref=NaN` into the number NaN, which firefox-profile then wrote
into prefs.js as the bare token `user_pref("some.pref", NaN);` instead of the
quoted string it writes for every other non-numeric value.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant