Skip to content

test(extensions): modal palette step waits for the modal frame's focus (#1261) - #1300

Merged
Juliusolsson05 merged 8 commits into
mainfrom
test/extension-modal-focus
Sep 25, 2026
Merged

Juliusolsson05 merged 8 commits into
mainfrom
test/extension-modal-focus

Conversation

@Juliusolsson05

@Juliusolsson05 Juliusolsson05 commented Sep 25, 2026 •

Copy link
Copy Markdown
Owner

Fixes #1261. Refs #1171 (the same failure). The product gap review found is #1307.

Plan: docs/plans/2026-09-25-extension-modal-focus.md (first commit; corrected after review).

Why

electron.system.test.ts fails intermittently at palette access inside a real modal shell timed out (three PRs hit it on 2026-09-25). The "does not declare activation" line in the log is expected output from a deliberate assert.rejects.

nativeInput.ts forwards a chord only while contents.focusedFrame is the extension frame. The step focused the modal's body and pressed Ctrl+Shift+K straight away, without confirming that Electron's focused frame had moved. On a slow runner, under Radix's own focus handling, it had not moved yet. (The first draft blamed frame selection; review showed only one managed frame exists at that point.)

Change (harness only)

  • One focusFrame(frame) helper for both the pane and modal palette steps. It focuses the frame's body, then waits until win.webContents.focusedFrame matches the frame by processId + routingId. The wait is bounded by the same 3 s budget and 20 ms step as waitBindings.
  • Excluding the old document when picking the modal frame stays, as a defence.
  • No existing budget is widened, and every assertion is kept.

Not fixed here

Verification

npx tsc -b is clean. This tier runs real Electron, which this loop doesn't launch locally, so the quality-gate run on the merge head is the check.

🤖 Generated with Claude Code

Juliusolsson05 and others added 2 commits September 25, 2026 07:00
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…frame has focus (#1261)

The step could focus the replaced pane frame (both exist briefly) and then
press Ctrl+Shift+K while Electron's focused frame was not the live
extension frame, which nativeInput ignores by design. Pick the new
document and wait for contents.focusedFrame to be it. No budget widened.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Juliusolsson05 and others added 3 commits September 25, 2026 07:18
… modal steps, frames compared by routing id

The pane step had the same unverified focus assumption as the modal step.
Both now wait until Electron's focusedFrame is the extension frame,
compared by processId + routingId (wrappers are not promised identical).
The stale-frame exclusion is documented as defensive: focus is the fix.
The product gap the wait no longer exercises (a modal whose iframe has
not taken focus drops the palette chord) is filed as #1307.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Juliusolsson05

Copy link
Copy Markdown
Owner Author

Final disposition (pre-merge), head 6ae2738. Merge-eligible only when this head (or a remerge of it) has a green quality-gate and contains current main.

Reviewer Round 1 Round 2
A (correctness) FIX-BEFORE-MERGE: the harness hides a real pre-focus product failure MERGE-READY for the harness; minor plan/body drift
B (tests) MERGE-READY (3 minors) —
C (root cause) MERGE-READY; the issue comment's cause was wrong —

Fixes and dispositions:

No budget is widened. Test-only; npx tsc -b is clean.

🤖 Generated with Claude Code

@Juliusolsson05

Copy link
Copy Markdown
Owner Author

Gate check before merge: head 6ae2738f contains main 54287d90. quality-gate and minimum-node-fixture-gate passed (run 36156968645). Three reviewers: A, B and C. Merging.

🤖 Generated with Claude Code

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.

bug(extensions): electron.system.test 'installed extension startup…' fails intermittently on CI (activation error + waitFor)

1 participant