Skip to content

[Feature] Make Web E2E match the Desktop GUI shell #269

@Astro-Han

Description

@Astro-Han

Problem

PawWork currently relies on Web Playwright E2E as the main automated safety net for GUI behavior, but the Web build (packages/app) does not faithfully match the shipped Electron Desktop shell (packages/desktop-electron). That weakens the value of E2E for the exact kinds of regressions we have been fixing around #412 and #413.

The current Web build reports platform: "web", while the shipped app runs through the Desktop platform path. Even though both builds share much of the same component tree, the Web preview and E2E environment differ in shell geometry, titlebar behavior, platform-gated UI, and capability fallbacks.

Concrete differences today include:

  • Web does not use the same desktop shell styling as Electron.
  • Web does not exercise the same macOS titlebar geometry and traffic-light spacing.
  • Web uses different root padding and main-frame treatment.
  • Web uses a 40px titlebar path while Desktop uses the 44px desktop standard.
  • Platform checks such as platform.platform === "desktop" can behave differently in E2E than in the shipped app.

This used to look like a developer-experience issue. After the May 4 regressions, it is clearer that this is also a test-confidence issue: if Web E2E is our main GUI safety net, it should exercise the product shell that users actually run.

Why this is P1

This is not a direct replacement for Electron/package smoke coverage. Native packaging failures, preload IPC, auto-updater behavior, OS dialogs, and packaged resource resolution still need Electron-specific checks.

The P1 reason is narrower: repeated GUI regressions are becoming expensive because our fastest, broadest GUI test layer does not match the shipped Desktop surface closely enough. That creates gaps around:

  • layout and titlebar geometry
  • side-panel and resize interaction state
  • route behavior inside the desktop shell
  • platform-gated desktop UI branches
  • visual review through Web previews and remote browser access

#412 and #413 should still be fixed at their own lowest correct layers. This issue reduces the chance that similar GUI regressions escape the main E2E layer again.

Desired outcome

The Web build should render and behave like the Desktop GUI shell for normal app flows, while keeping browser-safe implementations for capabilities that cannot exist in Web.

This should let us:

  1. Use bun --cwd packages/app dev for fast browser-based GUI debugging.
  2. Trust Web Playwright E2E for most Desktop GUI layout and interaction regressions.
  3. Keep Electron smoke focused on Electron-only risks instead of broad UI checking.
  4. Let Tailscale/browser previews show the same product shell users see in the app.
  5. Avoid launching Electron for every layout or interaction-state bug.

Proposed approach

Make the Web entry point use the Desktop visual/platform shell contract, likely by reporting platform: "desktop" with browser-safe capability implementations underneath.

Important distinction:

  • Visual/platform shell: should match Desktop.
  • Native capabilities: should degrade safely in Web.

Capability degradation strategy

Feature Desktop (Electron) Web after this change
Update check Native auto-updater Hidden or unavailable
Directory picker Native dialog Server-backed DialogSelectDirectory
Export session Save to local file Browser download
Open in Finder shell.openPath Disabled action with clear tooltip
Notifications Native or app-owned desktop path Browser-safe notification path or unavailable
Storage Electron store where needed Existing Web-safe storage path
Shell visuals Desktop shell Same Desktop shell
Titlebar geometry Desktop titlebar Same visual geometry, no native window controls

Non-goals

  • Do not replace Electron smoke or packaged-app verification.
  • Do not change route shapes.
  • Do not redesign side panels, session tabs, or settings.
  • Do not introduce a new platform type unless the implementation proves it is simpler than the existing contract.
  • Do not broaden this into native dialogs, updater behavior, signing, packaging, or preload IPC.
  • Do not change the responsive breakpoint behavior.

Acceptance criteria

  • Web renders the same desktop shell frame, spacing, background treatment, and main content geometry as Electron Desktop.
  • Web titlebar height and content offsets match the Desktop shell contract.
  • Existing Web E2E tests run against the Desktop visual shell by default.
  • E2E coverage is updated for at least one shell geometry assertion that would fail under the old Web-only shell.
  • Platform-gated Desktop UI branches used by layout, titlebar, side panels, and route shell behavior are exercised in Web E2E where browser-safe.
  • Browser-only capability fallbacks still work for project picking and export/download flows.
  • Electron-only capabilities remain hidden, disabled, or safely unavailable in Web.
  • Desktop smoke/package checks remain separate and still cover Electron-only startup and packaged resource risks.
  • No route-shape, UI redesign, or native capability expansion is included.

Relevant context

Recent issues that exposed the testing gap:

Current entry points and likely files:

  • Web entry: packages/app/src/entry.tsx
  • Desktop renderer entry: packages/desktop-electron/src/renderer/index.tsx
  • Platform contract: packages/app/src/context/platform.tsx
  • Shell CSS: packages/app/src/index.css
  • Titlebar: packages/app/src/components/titlebar.tsx
  • Layout shell: packages/app/src/pages/layout.tsx
  • Web E2E config: packages/app/playwright.config.ts
  • Desktop smoke: packages/desktop-electron/scripts/ci-smoke.ts

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High priorityappApplication behavior and product flowsenhancementNew feature or requestplatformElectron shell, OS integration, packaging, updater, signing, paths, and permissionsuiDesign system and user interface

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions