Skip to content

Conversation

@shige
Copy link
Member

@shige shige commented Dec 26, 2025

User description

Summary

  • Auto-hide TaskOverlay when navigating to other pages during task execution
  • Task continues running in the background after navigation

Changes

Problem

When running an App in Playground and navigating to Workspaces (or other pages) via the sidebar, the Task screen and destination page overlapped.

Solution

Added pathname change detection in TaskOverlay component. When the user navigates away, the overlay automatically hides while the task continues executing server-side.

Testing

  • Run an App in Playground
  • While "Creating task..." is shown, click "Workspaces" in sidebar
  • Verify the overlay disappears and Workspaces page displays correctly
  • Verify the task completes successfully (check /tasks page)

PR Type

Bug fix


Description

  • Auto-hide TaskOverlay when navigating away from current page

  • Task continues executing in background after navigation

  • Prevents overlay from overlapping destination page content


Diagram Walkthrough

flowchart LR
  A["User navigates to different page"] -- "pathname changes" --> B["useEffect detects change"]
  B -- "isVisible is true" --> C["hideOverlay called"]
  C -- "overlay hidden" --> D["Destination page displays"]
  C -- "task continues" --> E["Background execution"]
Loading

File Walkthrough

Relevant files
Bug fix
task-overlay.tsx
Add pathname change detection to auto-hide overlay             

apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx

  • Added usePathname hook to track current route
  • Added useRef to store previous pathname for comparison
  • Implemented useEffect hook to detect pathname changes
  • Auto-hide overlay when user navigates away while task is visible
  • Added hideOverlay action to store selector
+22/-7   

Note

Prevents the task overlay from persisting when navigating to other pages.

  • Detects route changes in TaskOverlay using usePathname and a useEffect; when the pathname changes and the overlay is visible, calls hideOverlay
  • Extends store selector to include hideOverlay; keeps existing overlay layout and animations intact

Written by Cursor Bugbot for commit 0cd7138. This will update automatically on new commits. Configure here.

Summary by CodeRabbit

  • Bug Fixes
    • Task overlay now automatically closes when navigating to a different route, improving the navigation experience.

✏️ Tip: You can customize this high-level summary in your review settings.

When navigating to other pages (e.g., Workspaces) while a task is running, the TaskOverlay remained visible and overlapped with the destination page.
This adds pathname change detection to auto-hide the overlay when the user navigates away, allowing the task to continue running in the background.
@shige shige self-assigned this Dec 26, 2025
Copilot AI review requested due to automatic review settings December 26, 2025 14:29
@vercel
Copy link

vercel bot commented Dec 26, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
giselle Ready Ready Preview, Comment Dec 26, 2025 2:32pm
ui Ready Ready Preview, Comment Dec 26, 2025 2:32pm

@giselles-ai
Copy link

giselles-ai bot commented Dec 26, 2025

Finished running flow.

Step 1
🟢
On Pull Request OpenedStatus: Success Updated: Dec 26, 2025 2:29pm
Step 2
🟢
Manual QAStatus: Success Updated: Dec 26, 2025 2:31pm
🟢
Prompt for AI AgentsStatus: Success Updated: Dec 26, 2025 2:31pm
Step 3
🟢
Create a Comment for PRStatus: Success Updated: Dec 26, 2025 2:33pm
Step 4
🟢
Create Pull Request CommentStatus: Success Updated: Dec 26, 2025 2:33pm

@changeset-bot
Copy link

changeset-bot bot commented Dec 26, 2025

⚠️ No Changeset found

Latest commit: 0cd7138

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

💥 An error occurred when fetching the changed packages and changesets in this PR
Some errors occurred when validating the changesets config:
The package or glob expression "giselles-ai" is specified in the `ignore` option but it is not found in the project. You may have misspelled the package name or provided an invalid glob expression. Note that glob expressions must be defined according to https://www.npmjs.com/package/micromatch.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 26, 2025

📝 Walkthrough

Walkthrough

The task overlay component now automatically hides when users navigate to different routes by monitoring pathname changes via Next.js hooks and invoking the hideOverlay action from the store.

Changes

Cohort / File(s) Summary
Task Overlay Auto-Hide
apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
Added pathname tracking via usePathname hook, stores previous pathname in ref, and triggers hideOverlay when route changes while overlay is visible; extended store selection to include hideOverlay and added useEffect to manage auto-hide logic

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 Hop, hop, navigate away!
The overlay knew just what to say—
When routes change quick with every bound,
It vanishes without a sound,
A rabbit's trick of subterfuge so sly!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately and specifically describes the main change: auto-hiding the task overlay when navigating to prevent overlapping issues.
Description check ✅ Passed The description is comprehensive and well-structured, covering summary, problem, solution, testing steps, and implementation details with diagrams and file walkthrough.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/task-overlay-navigation-overlap

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3031a8d and 0cd7138.

📒 Files selected for processing (1)
  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
🧰 Additional context used
📓 Path-based instructions (8)
**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx,js,jsx}: Favor clear, descriptive names and type annotations over clever tricks
If you need a multi-paragraph comment, refactor until intent is obvious

**/*.{ts,tsx,js,jsx}: Use async/await and proper error handling
Variables and functions should use camelCase naming
Booleans and functions should use is, has, can, should prefixes
Function names should clearly indicate purpose

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/development-guide.mdc)

**/*.{ts,tsx}: MUST run pnpm biome check --write [filename] after EVERY code modification
All code changes must be formatted using Biome before being committed
Use Biome for formatting with tab indentation and double quotes
Follow organized imports pattern (enabled in biome.json)
Use TypeScript for type safety; avoid any types
Use Next.js patterns for web applications
Use async/await for asynchronous code rather than promises
Error handling: use try/catch blocks and propagate errors appropriately
Use kebab-case for all filenames
Use PascalCase for React components and classes
Use camelCase for variables, functions, and methods
Use prefixes like is, has, can, should for boolean variables (e.g., isEnabled, hasPermission)
Use prefixes like is, has, can, should for boolean functions (e.g., isTriggerRequiringCallsign(), hasActiveSubscription()) instead of imperative verbs
Use verbs or verb phrases for function naming that clearly indicate purpose (e.g., calculateTotalPrice(), not process())

Use PascalCase for React component and class names

Use TypeScript and avoid any

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*.tsx

📄 CodeRabbit inference engine (.cursor/rules/development-guide.mdc)

Use functional components with React hooks

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*.{js,ts,tsx,jsx,py,java,cs,cpp,c,go,rb,php,swift,kt,scala,rs,dart}

📄 CodeRabbit inference engine (.cursor/rules/language-support.mdc)

Write all code comments in English

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*

📄 CodeRabbit inference engine (.cursor/rules/naming-guide.mdc)

Use kebab-case for file names (e.g., user-profile.ts, api-client.tsx)

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/naming-guide.mdc)

**/*.{js,ts,jsx,tsx}: Use camelCase for variable names, functions, and methods
Use verbs or verb phrases for function names to clearly indicate what the function does (e.g., calculateTotalPrice(), validateUserInput())
Use nouns or noun phrases for variable names to describe what the variable represents
Use boolean prefixes (is, has, can, should) for boolean variables and functions returning boolean values (e.g., isEnabled, hasPermission, isTriggerRequiringCallsign())

**/*.{js,ts,jsx,tsx}: Run pnpm biome check --write [filename] after every code change
All code must be formatted with Biome before commit

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*.{ts,tsx,js,jsx,css}

📄 CodeRabbit inference engine (AGENTS.md)

Files should use kebab-case naming

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
**/*.{tsx,ts}

📄 CodeRabbit inference engine (AGENTS.md)

Components should use PascalCase naming

Files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
🧠 Learnings (10)
📓 Common learnings
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: .cursor/rules/edit-workspace-tour.mdc:0-0
Timestamp: 2025-06-23T12:31:58.286Z
Learning: The tour uses React portals to render above other UI elements, ensuring overlays and highlights are not obstructed by the main application UI.
📚 Learning: 2025-11-25T03:05:31.051Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: .cursor/rules/edit-workspace-tour.mdc:0-0
Timestamp: 2025-11-25T03:05:31.051Z
Learning: Applies to internal-packages/workflow-designer-ui/src/editor/workspace-tour/workspace-tour.tsx : Update the `TourGlobalStyles` component in `workspace-tour.tsx` for animation changes

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-12-03T05:18:36.138Z
Learnt from: shige
Repo: giselles-ai/giselle PR: 2344
File: apps/studio.giselles.ai/app/stage/ui/navigation-rail/navigation-rail-expanded.tsx:14-20
Timestamp: 2025-12-03T05:18:36.138Z
Learning: In apps/studio.giselles.ai/app/stage/ui/navigation-rail/navigation-rail-expanded.tsx, "nav-action-history" is intentionally included in stageOnlyItemIds to hide it when the stage flag is disabled because the link destination is not yet implemented, even though it appears in the "Studio - Build Apps" section of navigation-items.ts.

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-11-25T03:07:07.498Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: internal-packages/workflow-designer-ui/src/editor/properties-panel/trigger-node-properties-panel/providers/github-trigger/AGENTS.md:0-0
Timestamp: 2025-11-25T03:07:07.498Z
Learning: Applies to internal-packages/workflow-designer-ui/src/editor/properties-panel/trigger-node-properties-panel/providers/github-trigger/components/{callsign,labels}*.tsx : Hide the 'Back' button in `input-callsign` and `input-labels` steps during reconfiguration mode to simplify UX.

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-11-25T03:07:19.740Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: internal-packages/workflow-designer-ui/src/new-editor/AGENTS.md:0-0
Timestamp: 2025-11-25T03:07:19.740Z
Learning: Applies to internal-packages/workflow-designer-ui/src/new-editor/**/*.{ts,tsx} : Replace context-wide reads from `src/editor/v2` with fine-grained selectors against the Zustand store

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-11-25T03:07:07.498Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: internal-packages/workflow-designer-ui/src/editor/properties-panel/trigger-node-properties-panel/providers/github-trigger/AGENTS.md:0-0
Timestamp: 2025-11-25T03:07:07.498Z
Learning: Applies to internal-packages/workflow-designer-ui/src/editor/properties-panel/trigger-node-properties-panel/providers/github-trigger/**/*.tsx : Wrap all state updates in `startTransition` for consistent UI behavior during configuration and reconfiguration flows.

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-11-25T03:07:19.740Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: internal-packages/workflow-designer-ui/src/new-editor/AGENTS.md:0-0
Timestamp: 2025-11-25T03:07:19.740Z
Learning: Applies to internal-packages/workflow-designer-ui/src/new-editor/**/*.{ts,tsx} : Lift actions into the store (e.g., `updateNode`) and call them from components needing mutations instead of passing mutation callbacks as props

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-11-25T03:07:19.740Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: internal-packages/workflow-designer-ui/src/new-editor/AGENTS.md:0-0
Timestamp: 2025-11-25T03:07:19.740Z
Learning: Applies to internal-packages/workflow-designer-ui/src/new-editor/components/**/*.{ts,tsx} : Wrap presentational components in `React.memo` only when their props are stable and derived via selectors

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-06-23T12:31:58.286Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: .cursor/rules/edit-workspace-tour.mdc:0-0
Timestamp: 2025-06-23T12:31:58.286Z
Learning: The tour uses React portals to render above other UI elements, ensuring overlays and highlights are not obstructed by the main application UI.

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
📚 Learning: 2025-06-23T12:31:58.286Z
Learnt from: CR
Repo: giselles-ai/giselle PR: 0
File: .cursor/rules/edit-workspace-tour.mdc:0-0
Timestamp: 2025-06-23T12:31:58.286Z
Learning: The workspace tour feature in `internal-packages/workflow-designer-ui/src/editor/workspace-tour/` is implemented using React and relies on a `TourStep` interface that defines each step's target (CSS selector), title, content, and placement.

Applied to files:

  • apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx
🧬 Code graph analysis (1)
apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx (1)
apps/studio.giselles.ai/app/(main)/stores/task-overlay-store.ts (1)
  • useTaskOverlayStore (33-42)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Cursor Bugbot
  • GitHub Check: check
🔇 Additional comments (3)
apps/studio.giselles.ai/app/(main)/ui/task-overlay.tsx (3)

4-5: LGTM! Clean import additions.

The imported hooks are exactly what's needed for pathname change detection: usePathname for tracking navigation, useEffect for the side effect, and useRef for comparing previous pathname values.


12-20: Well structured store selection.

Extending the store selection to include hideOverlay is correct and necessary for the auto-hide feature. The use of useShallow ensures optimal re-render behavior.


22-31: Excellent implementation of auto-hide behavior!

The pathname change detection logic is clean and correct:

  • The ref pattern properly tracks previous pathname to detect actual navigation events
  • The conditional check ensures overlay only hides when both pathname changes AND overlay is visible
  • The dependency array is complete and won't cause unnecessary re-runs (Zustand functions are stable)
  • Handles all navigation scenarios including browser back/forward (via usePathname)
  • The unconditional ref update keeps tracking in sync for subsequent navigations

This solution elegantly addresses the overlap issue while allowing the server-side task to continue executing.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes an overlapping issue where the TaskOverlay component remained visible when navigating to other pages during task execution. The solution adds automatic overlay hiding on navigation while allowing tasks to continue running in the background.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +27 to +30
if (prevPathnameRef.current !== pathname && isVisible) {
hideOverlay();
}
prevPathnameRef.current = pathname;
Copy link

Copilot AI Dec 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ref is updated after checking the condition, which means on the first render when isVisible is true, the overlay will be hidden even though the pathname hasn't actually changed. The ref should be updated in a way that skips the initial render, or the condition should check if prevPathnameRef.current is defined before hiding.

Copilot uses AI. Check for mistakes.
@qodo-free-for-open-source-projects

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢
No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🎫 No ticket provided
  • Create ticket/issue
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
🟢
Generic: Comprehensive Audit Trails

Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Meaningful Naming and Self-Documenting Code

Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Robust Error Handling and Edge Case Management

Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Error Handling

Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Logging Practices

Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Security-First Input Validation and Data Handling

Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

@qodo-free-for-open-source-projects

PR Code Suggestions ✨

No code suggestions found for the PR.

@giselles-ai
Copy link

giselles-ai bot commented Dec 26, 2025

🔍 QA Testing Assistant by Giselle

📋 Manual QA Checklist

Based on the changes in this PR, here are the key areas to test manually:

  • Task Overlay: Verify the task overlay automatically hides when navigating to another page while a task is running.
  • Task Overlay: Ensure the task overlay remains visible if the user stays on the same page while a task is running.
  • Task Overlay: Confirm the task overlay hides correctly when using the browser's native back-button navigation.
  • Task Overlay: Check that the task continues to run in the background after the overlay hides due to navigation.
  • Task Overlay: Verify that the task overlay still closes as expected when the task completes naturally without navigation.

✨ Prompt for AI Agents

Use the following prompts with Cursor or Claude Code to automate E2E testing:

📝 E2E Test Generation Prompt
You are an AI assistant tasked with creating an E2E test using Playwright. The following information provides context on a recent change, specific test scenarios to cover, and implementation guidelines.

### 1. Context Summary

*   **PR Description:** This pull request fixes a UI bug where the "Task Overlay" (a modal that appears when a long-running task is initiated) would remain on screen and overlap with the content of a new page if the user navigated away while the task was running.
*   **Functionality Change:** The `TaskOverlay` component now detects a change in the URL's `pathname`. When a navigation event occurs, the overlay is automatically hidden from view. Critically, the task itself continues to run in the background on the server.
*   **Key User Flow to Test:**
    1.  A user starts a task from a page (e.g., the "Playground").
    2.  The task overlay appears with a "Creating task..." message.
    3.  Before the task finishes, the user clicks a navigation link in the sidebar (e.g., "Workspaces").
    4.  The overlay should disappear, and the new page should be displayed correctly.
    5.  The user should be able to later verify that the background task completed successfully.

### 2. Test Scenarios

Create Playwright tests to cover the following scenarios:

*   **Scenario 1: (Happy Path) Overlay Hides on Navigation**
    *   **Description:** This is the primary success scenario that validates the fix.
    *   **Steps:**
        1.  Log in as a standard user.
        2.  Navigate to the "Playground" page (`/apps`).
        3.  Select an application that is known to trigger a task.
        4.  Click the "Run" button to start the task.
        5.  **Verify** that the task overlay becomes visible.
        6.  While the overlay is visible, immediately click the "Workspaces" link in the main sidebar.
        7.  **Assert** that the task overlay is no longer visible.
        8.  **Assert** that the URL has changed to the "Workspaces" page and its content (e.g., a heading) is visible.
        9.  Navigate to the global "Tasks" page (`/tasks`).
        10. **Assert** that the task you initiated appears in the list and its status is "Completed" (or eventually becomes "Completed" after a reasonable wait).

*   **Scenario 2: (Regression) Overlay Closes on Task Completion**
    *   **Description:** Ensure that the original functionality of the overlay (closing upon task completion) is not broken.
    *   **Steps:**
        1.  Log in as a standard user.
        2.  Navigate to the "Playground" page (`/apps`).
        3.  Select and run an application that triggers a quick task.
        4.  **Do not navigate away.**
        5.  Wait for the task to complete.
        6.  **Assert** that the task overlay automatically closes upon completion.
        7.  **Assert** that the user is still on the "Playground" page.

### 3. Playwright Implementation Instructions

Use the following guidelines to write clean, robust, and maintainable Playwright tests.

*   **Test File:**
    *   Create a new test file: `tests/e2e/task-overlay.spec.ts`.

*   **Authentication:**
    *   Use a global setup file or a `beforeEach` hook to handle user login. Assume a helper function `login(page)` exists or use a pre-saved `storageState`.

*   **Selectors (Use locator-based, user-facing selectors):**
    *   **Sidebar "Workspaces" Link:** `page.getByRole('link', { name: 'Workspaces' })`
    *   **Task Overlay:** The overlay is a `motion.div`. A reliable way to locate it is by its content. Use `page.getByText('Creating task...')` or a similar unique text that appears inside it.
    *   **"Workspaces" Page Heading:** To confirm navigation, find a unique, stable element on the destination page, like `page.getByRole('heading', { name: 'Workspaces' })`.
    *   **Tasks Page Status:** On the `/tasks` page, locate the task row and check its status. You might need a selector like `page.getByRole('row', { name: /your-task-name/i }).getByText('Completed')`.

*   **User Interactions & Assertions (Example for Scenario 1):**

    ```typescript
    import { test, expect } from '@playwright/test';

    test.describe('Task Overlay Navigation', () => {
      // Assume login is handled in a global setup or beforeEach

      test('should hide task overlay on navigation and complete task in background', async ({ page }) => {
        await test.step('Start a task from the Playground', async () => {
          await page.goto('/apps'); // Or your playground URL
          // Add steps to select and run an app that creates a task
          // e.g., await page.getByRole('button', { name: 'My Test App' }).click();
          // e.g., await page.getByRole('button', { name: 'Run' }).click();

          // Wait for the overlay to appear and verify it
          const taskOverlay = page.getByText('Creating task...');
          await expect(taskOverlay).toBeVisible({ timeout: 10000 });
        });

        await test.step('Navigate to another page while task is running', async () => {
          await page.getByRole('link', { name: 'Workspaces' }).click();

          // Assert the overlay is now hidden
          const taskOverlay = page.getByText('Creating task...');
          await expect(taskOverlay).toBeHidden();

          // Assert the new page has loaded
          await expect(page).toHaveURL(/.*\/workspaces/);
          await expect(page.getByRole('heading', { name: 'Workspaces' })).toBeVisible();
        });

        await test.step('Verify the task completed in the background', async () => {
          await page.goto('/tasks');

          // Use a robust locator to find the specific task and assert its completion status
          // This may require waiting for the status to update from "Running" to "Completed"
          const taskStatus = page.locator('.task-row-status:has-text("Completed")').first();
          await expect(taskStatus).toBeVisible({ timeout: 30000 }); // Generous timeout for background task
        });
      });

      // Add the second test for the regression scenario here
    });
    ```

*   **Data Setup/Teardown:**
    *   The test requires a pre-existing "App" in the Playground that can be run. The test should not be responsible for creating this app; it's a prerequisite.
    *   No specific teardown is needed unless the created task needs to be deleted, but for this test, simply verifying its existence is sufficient.

### 4. MCP Integration Guidelines

*   **Command Structure:** To run this specific test suite, use a grep pattern with a test tag. Add `@task-overlay` to the `test.describe` block.
    *   Example: `test.describe('@task-overlay Task Overlay Navigation', () => { ... });`
    *   **MCP Execution Command:** `mcp playwright:test -- --grep "@task-overlay"`
*   **Environment:** Ensure the `playwright.config.ts` has the correct `baseURL` set so that `page.goto('/apps')` resolves correctly. This is typically configured via an environment variable that MCP can provide.

### 5. CI-Ready Code Requirements

*   **Structure:** Use `test.describe()` to group related tests and `test.step()` within each test to provide clear, debuggable sections in the Playwright report.
*   **Naming:** Use descriptive names for test files (`task-overlay.spec.ts`), test suites (`Task Overlay Navigation`), and individual tests (`should hide...`).
*   **Error Handling:** Use `expect(locator).toBeVisible({ timeout: ... })` and other async matchers with appropriate timeouts to handle timing variations in the UI, preventing flaky tests.
*   **Parallelization:** The tests should be atomic and self-contained (especially regarding login state) to run reliably in parallel with other test files. The use of `storageState` for login is ideal for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants