[GH-ISSUE #2521] fix(electron): computed literal preferences become unnamed unknown values #838

New issue

Closed

opened 2026-10-15 18:28:54 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:28:54 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2521

Summary

Static analysis of a BrowserWindow with computed string-literal preference keys loses the exact names and values even though the source states them explicitly. It reports dynamic null preferences and changes the source's parse status to partial. A computed literal preload is still recovered as the effective preload path, so the same finding contains both an exact path and an unnamed unknown preference for that syntax.

Steps to reproduce

Use the source baseline and installed dependencies described under Runtime or environment.
Add this fixture as src/domain/javascript/computedPreference.test.ts.
Run npm run test:focused -- src/domain/javascript/computedPreference.test.ts.

import { expect, it } from "vitest";
import { analyzeJavaScriptStaticSource } from "./javascriptStaticAnalysis.js";

it("retains explicit computed literal preference observations", () => {
  const result = analyzeJavaScriptStaticSource(`
    const { BrowserWindow } = require("electron");
    new BrowserWindow({ webPreferences: {
      ["sandbox"]: true,
      ["preload"]: "./p.js"
    } });
  `);
  expect(result.electron.browser_windows[0]?.web_preferences).toEqual([
    { name: "preload", value: { status: "literal", value: "./p.js", expression: null } },
    { name: "sandbox", value: { status: "literal", value: true, expression: null } }
  ]);
  expect(result.electron.browser_windows[0]?.preload_path).toBe("./p.js");
  expect(result.parse_status).toBe("complete");
});

Expected behavior

The finding records named literal sandbox and preload values and reports complete parsing for this source. Brackets around an exact string literal do not make its property name unresolved. The effective preload path remains ./p.js.

Actual behavior

An executed observation test with this source returned two preferences named with the [dynamic@...] convention. Both had status dynamic and value null, while their expression fields retained the exact computed-key syntax and literal values. The parse status was partial with zero parser errors. The effective preload path was still ./p.js. Replacing the computed keys with plain property names returned complete status and the expected named literals. A genuinely dynamic key remained partial.

Evidence

Expected source: docs/javascript-artifact-reconstruction.md:227 describes recovery of explicit BrowserWindow options and preferences, and line 302 requires explicitly present values to remain observations. tests/boundary/filesystem/javascript-applications/electronOptionKeys.test.ts:74 already accepts a computed string-literal outer option key.
Failure source: src/domain/javascript/electronStaticAnalysisBrowser.ts:130 marks every computed preference as unknown, even after obtaining its semantic name. The focused static-analysis probe returned dynamic null preferences and partial parse status; src/domain/javascript/javascriptStaticAnalysis.ts:167 projects the unknown count into that status.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The observation test exited 0, with one test completed in 360ms, because it asserted the current failure and controls. The fixture above states the restoration assertions. The target source was parsed as inert data; no Electron process ran and no runtime isolation consequence is claimed.

Restoration check

The unchanged fixture returns the exact named literal preferences and complete parse status, while preserving the effective preload path. The plain-key control produces the same preferences. An actually unresolved computed key, such as [getKey()], continues to produce an unknown result and partial coverage.

Runtime or environment

Source baseline 8b181716aca2cb467be499cba226abfb5ae19141, Node v26.10.0, npm 11.19.1 and Vitest 5.0.3, with installed lockfile dependencies.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: The executed fixture loses exact structured preference observations and unnecessarily downgrades analysis coverage. The failure is bounded to computed literal keys; analysis still returns the source expression and effective preload path.
Workaround status: available
Workaround basis: The observed expression fields retain the exact literal keys and values. Inspecting those fields recovers these fixture values without editing the artifact or executing Electron, although the structured preference list and coverage remain incorrect.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2521 ## Summary Static analysis of a BrowserWindow with computed string-literal preference keys loses the exact names and values even though the source states them explicitly. It reports dynamic null preferences and changes the source's parse status to partial. A computed literal preload is still recovered as the effective preload path, so the same finding contains both an exact path and an unnamed unknown preference for that syntax. ## Steps to reproduce 1. Use the source baseline and installed dependencies described under Runtime or environment. 2. Add this fixture as `src/domain/javascript/computedPreference.test.ts`. 3. Run `npm run test:focused -- src/domain/javascript/computedPreference.test.ts`. ```ts import { expect, it } from "vitest"; import { analyzeJavaScriptStaticSource } from "./javascriptStaticAnalysis.js"; it("retains explicit computed literal preference observations", () => { const result = analyzeJavaScriptStaticSource(` const { BrowserWindow } = require("electron"); new BrowserWindow({ webPreferences: { ["sandbox"]: true, ["preload"]: "./p.js" } }); `); expect(result.electron.browser_windows[0]?.web_preferences).toEqual([ { name: "preload", value: { status: "literal", value: "./p.js", expression: null } }, { name: "sandbox", value: { status: "literal", value: true, expression: null } } ]); expect(result.electron.browser_windows[0]?.preload_path).toBe("./p.js"); expect(result.parse_status).toBe("complete"); }); ``` ## Expected behavior The finding records named literal sandbox and preload values and reports complete parsing for this source. Brackets around an exact string literal do not make its property name unresolved. The effective preload path remains `./p.js`. ## Actual behavior An executed observation test with this source returned two preferences named with the `[dynamic@...]` convention. Both had status `dynamic` and value null, while their expression fields retained the exact computed-key syntax and literal values. The parse status was `partial` with zero parser errors. The effective preload path was still `./p.js`. Replacing the computed keys with plain property names returned complete status and the expected named literals. A genuinely dynamic key remained partial. ## Evidence - Expected source: `docs/javascript-artifact-reconstruction.md:227` describes recovery of explicit BrowserWindow options and preferences, and line 302 requires explicitly present values to remain observations. `tests/boundary/filesystem/javascript-applications/electronOptionKeys.test.ts:74` already accepts a computed string-literal outer option key. - Failure source: `src/domain/javascript/electronStaticAnalysisBrowser.ts:130` marks every computed preference as unknown, even after obtaining its semantic name. The focused static-analysis probe returned dynamic null preferences and partial parse status; `src/domain/javascript/javascriptStaticAnalysis.ts:167` projects the unknown count into that status. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The observation test exited 0, with one test completed in 360ms, because it asserted the current failure and controls. The fixture above states the restoration assertions. The target source was parsed as inert data; no Electron process ran and no runtime isolation consequence is claimed. ## Restoration check The unchanged fixture returns the exact named literal preferences and complete parse status, while preserving the effective preload path. The plain-key control produces the same preferences. An actually unresolved computed key, such as `[getKey()]`, continues to produce an unknown result and partial coverage. ## Runtime or environment Source baseline `8b181716aca2cb467be499cba226abfb5ae19141`, Node v26.10.0, npm 11.19.1 and Vitest 5.0.3, with installed lockfile dependencies. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The executed fixture loses exact structured preference observations and unnecessarily downgrades analysis coverage. The failure is bounded to computed literal keys; analysis still returns the source expression and effective preload path. - Workaround status: available - Workaround basis: The observed expression fields retain the exact literal keys and values. Inspecting those fields recovers these fixture values without editing the artifact or executing Electron, although the structured preference list and coverage remain incorrect.

bsakaguchi

2026-10-15 18:28:54 +00:00

closed this issue
added the
area: runtime

bug
labels

bsakaguchi referenced this issue

2026-10-16 21:16:38 +00:00

[PR #838] [MERGED] fix(mcp): isolate optional observation adapter failures #2276

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#838

No description provided.

Rows
Columns