paperclip/tests/storybook-visual
Dotta 9c941169a6
fix(ui): keep new task dialog visible above mobile keyboard (#11281)
<!-- Write all pull request text in Simplified Technical English
(ASD-STE100): short sentences, one instruction per sentence, simple
approved vocabulary, and the active voice. -->

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Operators create tasks in a dialog that includes the assignee and
project fields.
> - Mobile browsers reduce and offset the visual viewport when the
on-screen keyboard opens.
> - The dialog used layout viewport units, so its upper fields could
move off-screen while the user typed.
> - This pull request makes the dialog follow the live visual viewport
and keeps the focused editor visible.
> - The benefit is that operators can see the task context and the field
they edit on mobile devices.

## Linked Issues or Issue Description

**What happened?**

On mobile browsers, opening the keyboard in the new-task dialog could
move the assignee and project fields above the visible screen. The
active editor could also become difficult to see.

**Expected behavior**

The full dialog must stay inside the visible browser area. The active
editor and task controls must remain reachable while the on-screen
keyboard is open.

**Steps to reproduce**

1. Open Paperclip on a mobile browser.
2. Open the new-task dialog.
3. Focus the title or description editor to open the on-screen keyboard.
4. Observe that the upper fields can move outside the visible viewport.

**Paperclip version or commit**

Reproduced before commit `838cdbb325` on `master`.

**Deployment mode**

Local dev (`pnpm dev`) in a mobile browser viewport.

## What Changed

- Read `window.visualViewport` while the dialog is open.
- Apply token-based dialog geometry when the visual viewport is
constrained.
- Keep the focused editor visible after viewport resize and scroll
events.
- Add unit coverage for visual viewport updates and focus scrolling.
- Add Playwright coverage for mobile, tablet, desktop keyboard, and
unconstrained desktop layouts.

## Verification

- `pnpm exec vitest run ui/src/components/NewIssueDialog.test.tsx` — 27
tests passed.
- `pnpm --filter @paperclipai/ui typecheck` — passed.
- `pnpm check:token-gates` — passed with all gates clean.
- `pnpm --filter @paperclipai/ui build-storybook` — passed.
- `pnpm exec playwright test
tests/storybook-visual/new-issue-dialog-viewport.spec.ts --config
tests/storybook-visual/playwright.config.ts` — 4 tests passed.

## Risks

- Low risk. The custom geometry only activates when
`visualViewport.height` is less than `window.innerHeight`.
- Browsers without the Visual Viewport API keep the existing dialog
primitive behavior.
- The browser test checks hit targets and visible bounds at mobile,
tablet, and desktop widths.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

- OpenAI Codex, GPT-5. The session used reasoning, repository tools,
shell execution, and browser automation. The service did not expose the
context-window size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-08-12 11:49:05 -04:00
..
README.md
baseline-manifest.json
new-issue-dialog-viewport.spec.ts
playwright.config.ts
storybook-visual.spec.ts

README.md

Storybook Visual Baselines

The visual suite compares built Storybook stories against PNG snapshots stored outside git. The checked-in manifest at baseline-manifest.json pins the immutable archive URL, SHA-256, byte size, snapshot count, and capture environment.

Commands

pnpm storybook-visual:baseline download
pnpm storybook-visual:baseline verify
pnpm test:storybook-visual
pnpm test:storybook-visual:update

download fetches the archive, verifies its SHA-256 and byte size, unpacks it to tests/storybook-visual/.snapshots/, and checks the PNG count. The same snapshot directory can be overridden with STORYBOOK_VISUAL_SNAPSHOT_DIR.

Known Limitation: Linux Baselines

Storybook visual baselines are platform-locked. The checked-in manifest records the capture environment as ubuntu-24.04, and Playwright compares screenshots with maxDiffPixels: 0. Pixel-exact results are only meaningful when local runs use the same Linux/Ubuntu capture platform as the baseline.

macOS, Windows, and other non-matching local environments can produce false-positive diffs from font rasterization and subpixel rendering differences. Use the Storybook Visual GitHub Actions workflow on ubuntu-latest as the source of truth for cross-platform review, or run the suite locally in a matching Linux environment before accepting or updating baselines.

CI and Review Artifacts

Storybook visual tests are opt-in while the suite stabilizes. Add the storybook-visual label to a pull request, or run the Storybook Visual workflow manually, to download the pinned baseline, build Storybook, and run the Playwright visual suite on GitHub Actions.

The workflow uploads tests/storybook-visual/playwright-report/ and tests/storybook-visual/test-results/ as a storybook-visual-report-* artifact on every run. When screenshots differ, Playwright writes the actual, expected, and diff PNGs into test-results, so reviewers can inspect the failure without rerunning the suite locally.

Normal PR visual runs use repository read-only permissions and never upload or modify baseline objects. To review intentional visual changes before updating baseline-manifest.json, run the workflow manually with update_snapshots enabled. That produces a storybook-visual-baseline-review-* artifact containing the packed candidate snapshot archive for review. Publishing that bundle to the baseline bucket still requires the explicit maintainer upload command below.

Updating Baselines

  1. Run pnpm test:storybook-visual:update after reviewing intentional visual diffs.
  2. Run pnpm storybook-visual:baseline pack to create tests/storybook-visual/baseline-review/snapshots.tgz.
  3. Upload the archive from a trusted maintainer environment with STORYBOOK_VISUAL_S3_URI=s3://bucket/baselines/storybook-visual/<sha>/snapshots.tgz pnpm storybook-visual:baseline upload.
  4. Copy the printed snapshotCount and archive fields into baseline-manifest.json.

Generated snapshots, review bundles, Playwright reports, and downloaded caches are ignored by git.