[PR #808] [MERGED] fix(browser): distinguish computed call keys from identifiers #2255

New issue

Closed

opened 2026-10-16 21:16:21 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/808
Author: @rudycelekli
Created: 10/6/2026
Status: ✅ Merged
Merged: 10/7/2026
Merged by: @N0zoM1z0

Base: main ← Head: fix/browser-computed-call-evidence-20261006

📝 Commits (1)

ef479bd fix(browser): distinguish computed call keys from identifiers

📊 Changes

2 files changed (+47 additions, -7 deletions)

View changed files

📝 src/domain/webBundleAnalyzer.test.ts (+42 -0)
📝 src/domain/webBundleAnalyzerAst.ts (+5 -7)

📄 Description

Summary

Use the existing semantic property-key helper when naming captured browser calls. A computed identifier such as window[fetch]() is a variable lookup, not a literal .fetch call: a real page where that variable equals render currently gains a fabricated endpoint. The same mistake fabricates require chunk edges and WebMCP declarations. Direct and literal computed methods remain recognized; an unknown receiver with a literal method retains the existing method-name heuristic.

Verification

Actual owned Chrome154 + loopback page through public CdpBrowserProvider.analyzeBundle: before, render-only calls are misreported as a fetch endpoint and require edge. Runtime page results independently show they invoke render. After, those findings disappear while three real direct/literal/nested-receiver literal fetch calls remain.
Focused web bundle analyzer tests: 12 passed, including direct/literal fetch, require and WebMCP controls. The new negative case fails on unchanged main.
npm run check: all five tasks passed, 129 existing warnings and zero errors. npm run check:fast: both tasks passed. Existing locked Node24/Vitest5/TypeScript7 reused.

Scope

This changes the browser captured-bundle analyzer. Owner-merged #536 corrected the separate static JavaScript analyzer; it did not modify this browser consumer. This remains syntax-based evidence: no dynamic evaluation, binding resolution, or broader optional-call support is added. Other operating systems and hosted full native matrices were not locally run.

AI-assisted implementation and tests; I reviewed the change and ran the reported checks.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/808 **Author:** [@rudycelekli](https://github.com/rudycelekli) **Created:** 10/6/2026 **Status:** ✅ Merged **Merged:** 10/7/2026 **Merged by:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Base:** `main` ← **Head:** `fix/browser-computed-call-evidence-20261006` --- ### 📝 Commits (1) - [`ef479bd`](https://github.com/morluto/rea/commit/ef479bd74d72b962c5a859c5ced0066ee6c591fc) fix(browser): distinguish computed call keys from identifiers ### 📊 Changes **2 files changed** (+47 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `src/domain/webBundleAnalyzer.test.ts` (+42 -0) 📝 `src/domain/webBundleAnalyzerAst.ts` (+5 -7) </details> ### 📄 Description ## Summary Use the existing semantic property-key helper when naming captured browser calls. A computed identifier such as `window[fetch]()` is a variable lookup, not a literal `.fetch` call: a real page where that variable equals `render` currently gains a fabricated endpoint. The same mistake fabricates `require` chunk edges and WebMCP declarations. Direct and literal computed methods remain recognized; an unknown receiver with a literal method retains the existing method-name heuristic. ## Verification - Actual owned Chrome154 + loopback page through public `CdpBrowserProvider.analyzeBundle`: before, render-only calls are misreported as a fetch endpoint and require edge. Runtime page results independently show they invoke `render`. After, those findings disappear while three real direct/literal/nested-receiver literal fetch calls remain. - Focused web bundle analyzer tests: 12 passed, including direct/literal fetch, require and WebMCP controls. The new negative case fails on unchanged main. - `npm run check`: all five tasks passed, 129 existing warnings and zero errors. `npm run check:fast`: both tasks passed. Existing locked Node24/Vitest5/TypeScript7 reused. ## Scope This changes the browser captured-bundle analyzer. Owner-merged #536 corrected the separate static JavaScript analyzer; it did not modify this browser consumer. This remains syntax-based evidence: no dynamic evaluation, binding resolution, or broader optional-call support is added. Other operating systems and hosted full native matrices were not locally run. AI-assisted implementation and tests; I reviewed the change and ran the reported checks. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

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

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-10-17 21:01:59 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

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#2255

No description provided.

Rows
Columns