fix(ui): refit read-file icon into 0-20 viewBox#964
Conversation
The read-file glyph's port-side rescale into the chrome icon registry overshot the canvas: its rendered bbox extended to y=22.10, past the viewBox's lower edge, so the svg's UA overflow:hidden clipped the document's bottom edge in every tool-row summary that shows 'read N files'. Among the 91 icons in the registry, read-file was the only one crossing the 0-20 bounds. The artwork is correct (newly drawn in the v4 slice08 batch alongside skill and thinking — those two fit fine); only the translate/scale 'rescale to 20x20' step documented in docs/design/pawwork-chrome-icon-imagegen-v4-slice08/README.md was off for this one glyph. Recompute the transform so the bbox lands at x:[2.76,17.24] y:[0.88,19.12] — centered with 1-unit margin and matching the family height of its v4 batchmates. Add packages/app/e2e/icon-viewbox-fit.spec.ts: a browser-rendered getBBox compliance check that scans every entry of the icons registry and asserts the rendered geometry stays within 0..20. Catches any future port that overshoots a side before it ships.
📝 WalkthroughWalkthroughThis PR adds a smoke test that validates all icon glyphs fit within a ChangesIcon ViewBox Fit Validation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Code Review
This pull request introduces a new Playwright smoke test (icon-viewbox-fit.spec.ts) to ensure that all SVG icons in the registry fit within the standard 0 0 20 20 viewBox. It also adjusts the scale and translation properties of the read-file icon in icon.tsx to resolve a clipping issue. The reviewer pointed out that the parsing logic in loadIcons is fragile and could easily break with minor formatting changes, and provided a robust regular expression-based suggestion to make the test more resilient.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/app/e2e/icon-viewbox-fit.spec.ts`:
- Line 22: Replace the top-level import so the E2E spec uses the repo fixtures:
change the import of { test, expect } to come from "../fixtures" rather than
"`@playwright/test`" (leave the imported symbols { test, expect } unchanged) so
the spec file icon-viewbox-fit.spec.ts adheres to the packages/app/e2e fixture
contract.
🪄 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 Plus
Run ID: a3e04fa8-ff36-42e2-943e-69711a326f29
📒 Files selected for processing (2)
packages/app/e2e/icon-viewbox-fit.spec.tspackages/ui/src/components/icon.tsx
Perf delta summaryComparator: pass
|
A picture next to the regression test: read-file rendered with both the pre-fix and post-fix transform, plus skill and thinking as v4-batch references, each with a red dashed viewBox edge marker. Regenerate with `bun run snap icon-viewbox` — the grid lands at docs/design/preview/screenshots/icon-viewbox.png (gitignored).
Two review findings from CodeRabbit and Gemini:
- packages/app/e2e/AGENTS.md mandates importing `test` / `expect` from
`../fixtures`, not `@playwright/test` directly. Both the
icon-viewbox-fit spec and the icon-viewbox snap target violated that;
switch them to the fixture imports. Fixtures are lazy, so the suites
that only use `page` don't pull in the opencode backend.
- Regex-parsing icon.tsx to read the glyph table was fragile (any
formatting drift could silently skip glyphs). Replace with a direct
`import { icons } from "@opencode-ai/ui/icon"` so the suite reads
the same exported value the app ships.
Bump PawWork desktop release version to 2026.5.29. Changes since v2026.5.28: - feat(settings): move Connections to Integrations + global toast monitor (#975) - feat(ui): display cache hit rate with one decimal place (#967) - fix: stabilize session opening state (#969) - fix(session): repair stale paginated question blockers (#962) - fix(ui): refit read-file icon into 0-20 viewBox (#964) - fix: allow running tools to expand - fix: add run lifecycle diagnostics - fix: harden Electron repair fallback - refactor: remove legacy theme choices - ci: stabilize e2e Playwright install and PR triage paths Verification: diff scope matches prior release bump (#958) — only the version string in packages/desktop-electron/package.json and the workspace entry in bun.lock. All CI checks green (e2e-artifacts required a rerun due to Playwright browser install flake unrelated to this change).
Summary
Refit the
read-filechrome icon so its rendered geometry stays inside the0 0 20 20viewBox. Add an end-to-end regression test that locks every entry in the icon registry to the same bound.Why
In every "read N files" tool-row summary, the
read-filedocument glyph's bottom edge was clipped on screen. The svg element's UAoverflow: hiddenwas doing the clipping because the glyph's<g transform>rescaled the traced path slightly too tall — its rendered bbox extended to y≈22.10, past the 20-unit viewBox edge.read-filewas the only one of the 91 entries in the chrome icon registry to cross the 0..20 bounds. Its v4-batch siblingsskillandthinking, drawn with the same negative-Y-scale trace pipeline, were rescaled correctly. Only the "Claude rescales to 20×20" step documented indocs/design/pawwork-chrome-icon-imagegen-v4-slice08/README.mdwas off for this one glyph.The artwork itself is the user's intended new drawing; only the fit transform was wrong.
Related Issue
No issue — surfaced by direct user report of bottom-truncated
read-fileicons in chat tool rows.Human Review Status
Approved by @Astro-Han
Review Focus
packages/ui/src/components/icon.tsx:72: derived by measuring the raw path's untransformed bbox in chromium, then computing translate/scale so the rendered bbox lands atx:[2.76, 17.24] y:[0.88, 19.12]— centered, with ~1-unit margin and the same height asskill/thinking.packages/app/e2e/icon-viewbox-fit.spec.ts): uses chromium's nativegetBBoxrather than a pixel snap, so the assertion is geometric, deterministic, and prints exactly which side and by how much an offending glyph overflows.Risk Notes
Visible UI:
read-file's on-screen size and position shift slightly — it now sits centered with ~1-unit margin instead of overhanging the bottom edge by ~10% of the icon height. No other icon is touched. No platform/packaging/copy/data/permissions surface.How To Verify
Screenshots or Recordings
Checklist
bug,enhancement,task,documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.app,ui,platform,harness,ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.P0,P1,P2,P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.Pending,Approved by @<reviewer>, orNot required: <reason>(default isPending; "not required" is restricted to bot-authored low-risk PRs).dev, and my PR title and commit messages use Conventional Commits in English.