Skip to content

update google sdk for gemini. Better frame context cleanup - #68

Merged
Dingway98 merged 2 commits into
mainfrom
update-gemini-sdk
Dec 3, 2025
Merged

Dingway98 merged 2 commits into
mainfrom
update-gemini-sdk

fix aggressive removal of event listeners

cef2693
Select commit
Loading
Failed to load commit list.
Cursor / Cursor Bugbot completed Dec 1, 2025 in 5m 9s

Bugbot Review

Bugbot Analysis Progress (5m 12s elapsed)

✅ Gathered PR context (2s)
✅ Analyzed code changes (1s)
✅ Completed bug detection — 1 potential bug found (4m 56s)
✅ Validation and filtering completed (0s)
✅ Posted analysis results — 1 bug reported (13s)
✅ Analysis completed successfully (0s)

Final Result: Bugbot completed review and found 1 potential issue

Request ID: serverGenReqId_7b2b2ec4-55fe-4bc0-a4b6-d1251fad0507

Details

Bug: Cross-origin frame processing accidentally removed from loop

The collectCrossOriginFrameData call and processedCrossOriginFrames.add(frameId) were removed from the cross-origin frame branch, but the conditional structure was left intact. Now when isCrossOrigin && frameId && session is true and the frame hasn't been processed, the code falls through without doing anything. The processedCrossOriginFrames.has(frameId) check at line 474 will always be false since nothing populates the set in this loop anymore. While OOPIF processing later handles frames from frameContextManager.getOOPIFs(), any cross-origin frames discovered in maps.frameMap that aren't tracked as OOPIFs will be silently skipped.

src/context-providers/a11y-dom/index.ts#L472-L479

if (isCrossOrigin && frameId && session) {
if (processedCrossOriginFrames.has(frameId)) {
continue;
}
} else {
sameOriginFrames.push([frameIndex, frameInfo]);
}

Fix in Cursor Fix in Web