You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Use bun --cwd packages/app dev for fast browser-based GUI debugging.
Trust Web Playwright E2E for most Desktop GUI layout and interaction regressions.
Keep Electron smoke focused on Electron-only risks instead of broad UI checking.
Let Tailscale/browser previews show the same product shell users see in the app.
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.
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:
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:
#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:
bun --cwd packages/app devfor fast browser-based GUI debugging.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:
Capability degradation strategy
DialogSelectDirectoryshell.openPathNon-goals
Acceptance criteria
Relevant context
Recent issues that exposed the testing gap:
Current entry points and likely files:
packages/app/src/entry.tsxpackages/desktop-electron/src/renderer/index.tsxpackages/app/src/context/platform.tsxpackages/app/src/index.csspackages/app/src/components/titlebar.tsxpackages/app/src/pages/layout.tsxpackages/app/playwright.config.tspackages/desktop-electron/scripts/ci-smoke.ts