Fix MI Welcome Page auto-opening when Test Explorer opened on non-MI project (#1371)#1960
Fix MI Welcome Page auto-opening when Test Explorer opened on non-MI project (#1371)#1960SasinduDilshara wants to merge 2 commits intomainfrom
Conversation
Change `newProject` state machine initial substate from `viewLoading` to `viewReady` so that the MI Welcome webview is only opened in response to an explicit OPEN_VIEW event (e.g., MI.openWelcome command), not on passive activation events like `onView:MI.mock-services` triggered by Test Explorer. Adds unit tests (nonMiProjectActivation.test.ts) and E2E tests (nonMiProjectActivation.spec.ts) as regression guards. Fixes: wso2/mi-vscode#1371
Issue Analysis — [Issue #1371]: MI Welcome Page opens when accessing VS Code Test Explorer (even for non-MI projects)Classification
Reproducibility
Why the Bug Was Not ReproducedThe reproduction is blocked by a chain of preconditions that did not align in this environment:
Root Cause AnalysisThe bug mechanism is confirmed by source code inspection of the installed extension at Trigger path:
Why the
Static configuration evidence (from
Test Coverage Assessment
|
Fix Plan — Issue #1371Dev Test Result
Changes Made
Root Cause & Fix ExplanationRoot cause: The Fix: Changed Known IssuesNone — dev test passed. The explicit |
📝 WalkthroughWalkthroughThe PR addresses issue Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fix Verification ReportIssue: wso2/mi-vscode#1371 Reproduction Steps Executed
ResultThe MI Welcome Page did not auto-open when the Testing view was opened on a non-MI workspace.
Fix mechanism confirmed: The EvidenceExtension Host Log (confirms MI extension activation on non-MI workspace)Playwright Test OutputScreenshots
Source Fix (confirmed in repo)File: newProject: {
entry: () => logDebug("State Machine: Entering 'newProject' state"),
initial: "viewReady", // ← FIX: was "viewLoading" (auto-opened Welcome webview)
states: {
viewLoading: { ... invoke: { src: 'openWebPanel' } ... },
viewReady: {
// Passive state — only opens webview on explicit OPEN_VIEW event
on: { OPEN_VIEW: { target: "viewLoading", ... } }
}
}
} |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@workspaces/mi/mi-extension/src/test/e2e-playwright-tests/nonMiProjectActivation.spec.ts`:
- Around line 43-52: The test currently calls initTest(...) once inside
test.describe, causing shared beforeAll/afterAll and a single VS Code session;
change the structure so each activation scenario gets its own fresh session by
moving initTest(...) into separate test.describe blocks or by creating two
distinct describe() suites that each call initTest(true, true, false, ...)
independently (referencing createTests(), test.describe, and initTest) so
beforeAll/afterAll run per-scenario and the cold-activation case is exercised in
its own fresh extension/workspace.
In `@workspaces/mi/mi-extension/src/test/suite/nonMiProjectActivation.test.ts`:
- Around line 151-162: The test currently only asserts that sm.context().view is
defined; update the assertion to check that the view equals the specific
MACHINE_VIEW.Welcome value. Locate the test "newProject state machine context
carries Welcome view type" and replace the loose check on ctx.view (from
getStateMachine(...) and waitForTopState(...)) with a strict equality/assertion
against MACHINE_VIEW.Welcome (use the same ctx = sm.context() as any and
assert.strictEqual or equivalent to ensure ctx.view === MACHINE_VIEW.Welcome).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 84260bd8-a055-4376-90fe-37de00a2fe6d
📒 Files selected for processing (5)
workspaces/mi/mi-extension/package.jsonworkspaces/mi/mi-extension/src/stateMachine.tsworkspaces/mi/mi-extension/src/test/e2e-playwright-tests/nonMiProjectActivation.spec.tsworkspaces/mi/mi-extension/src/test/e2e-playwright-tests/test.list.tsworkspaces/mi/mi-extension/src/test/suite/nonMiProjectActivation.test.ts
| export default function createTests() { | ||
| test.describe('Issue #1371 — Non-MI Project Activation', { | ||
| tag: '@issue1371', | ||
| }, async () => { | ||
| // `newProject: true` → always start with a clean workspace directory | ||
| // `skipProjectCreation: true` → do NOT run createProject(); the workspace | ||
| // stays empty (no pom.xml) so the MI extension | ||
| // will not detect an MI project. | ||
| initTest(true, true, false, undefined, undefined, 'issue1371'); | ||
|
|
There was a problem hiding this comment.
Run each activation scenario in a fresh VS Code session.
initTest() installs beforeAll/afterAll, so calling it once here makes both cases share the same workspace and extension instance. That means the second test no longer verifies cold activation on a non-MI Maven workspace, which weakens the regression guard for the exact bug this suite is targeting. Consider isolating each scenario in its own describe/initTest(...) block or otherwise relaunching between tests.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@workspaces/mi/mi-extension/src/test/e2e-playwright-tests/nonMiProjectActivation.spec.ts`
around lines 43 - 52, The test currently calls initTest(...) once inside
test.describe, causing shared beforeAll/afterAll and a single VS Code session;
change the structure so each activation scenario gets its own fresh session by
moving initTest(...) into separate test.describe blocks or by creating two
distinct describe() suites that each call initTest(true, true, false, ...)
independently (referencing createTests(), test.describe, and initTest) so
beforeAll/afterAll run per-scenario and the cold-activation case is exercised in
its own fresh extension/workspace.
| test('newProject state machine context carries Welcome view type', async () => { | ||
| // After transitioning to newProject, context.view should be set to | ||
| // MACHINE_VIEW.Welcome — but the webview must NOT be opened yet. | ||
| const sm = getStateMachine(tempDir); | ||
| await waitForTopState(sm, 'newProject'); | ||
|
|
||
| const ctx = sm.context() as any; | ||
| assert.ok( | ||
| ctx.view !== undefined, | ||
| 'State machine context must have a view property after entering newProject' | ||
| ); | ||
| }); |
There was a problem hiding this comment.
Assert the actual Welcome view, not just “some view”.
This test currently passes for any non-undefined ctx.view, so it would miss a regression that routes non-MI activation to the wrong screen. Please assert the specific MACHINE_VIEW.Welcome value here.
Suggested tightening
import * as fs from 'fs';
import { isOldProjectOrWorkspace, getStateMachine, deleteStateMachine } from '../../stateMachine';
import { webviews } from '../../visualizer/webview';
+import { MACHINE_VIEW } from '@wso2/mi-core';- assert.ok(
- ctx.view !== undefined,
- 'State machine context must have a view property after entering newProject'
- );
+ assert.strictEqual(
+ ctx.view,
+ MACHINE_VIEW.Welcome,
+ 'State machine context must point to MACHINE_VIEW.Welcome after entering newProject'
+ );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workspaces/mi/mi-extension/src/test/suite/nonMiProjectActivation.test.ts`
around lines 151 - 162, The test currently only asserts that sm.context().view
is defined; update the assertion to check that the view equals the specific
MACHINE_VIEW.Welcome value. Locate the test "newProject state machine context
carries Welcome view type" and replace the loose check on ctx.view (from
getStateMachine(...) and waitForTopState(...)) with a strict equality/assertion
against MACHINE_VIEW.Welcome (use the same ctx = sm.context() as any and
assert.strictEqual or equivalent to ensure ctx.view === MACHINE_VIEW.Welcome).
|
|
3 participants
Summary
newProjectstate initial substate fromviewLoadingtoviewReadyinstateMachine.tsso the MI Welcome webview only opens on an explicitOPEN_VIEWevent, not passively ononView:MI.mock-servicesactivationnonMiProjectActivation.spec.ts) and unit test (nonMiProjectActivation.test.ts) to prevent regressionsRoot Cause
When VS Code fires the implicit
onView:MI.mock-servicesactivation event (triggered by the user opening Test Explorer), the MI extension activates and the state machine enters thenewProjectstate. BecausenewProjecthadinitial: "viewLoading", it immediately invokedopenWebPanel, showing the MI Welcome webview panel to users working on non-MI projects.Fix
The
viewReadysubstate is passive — it only opens the webview on an explicitOPEN_VIEWevent (e.g., theMI.openWelcomecommand or the "Create New Project" toolbar button). This preserves the intended UX while preventing the unwanted auto-open behavior.Test Plan
workspaceContains:pom.xml; confirmed MI Welcome Page did NOT auto-opensrc/test/suite/nonMiProjectActivation.test.tssrc/test/e2e-playwright-tests/nonMiProjectActivation.spec.tsChanges
workspaces/mi/mi-extension/src/stateMachine.tsinitial: "viewLoading"→initial: "viewReady"innewProjectstateworkspaces/mi/mi-extension/src/test/suite/nonMiProjectActivation.test.tsworkspaces/mi/mi-extension/src/test/e2e-playwright-tests/nonMiProjectActivation.spec.tsworkspaces/mi/mi-extension/src/test/e2e-playwright-tests/test.list.ts🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
Bug Fixes
Tests