mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-27 19:35:13 +01:00
conreo
b46d1ab77b
## Thinking Path > - The Paperclip board is used from phones, and `ui/public/site.webmanifest` is what a browser reads when someone adds the board to a home screen. > - That manifest asks for `display: "browser"`. Chrome installs a web app only when `display` is `fullscreen`, `standalone` or `minimal-ui`; with `browser` it answers `manifest-display-not-supported` and adds a shortcut rather than an app, so every launch keeps the address bar. > - The user interface already implements the no-browser-chrome case. `StandaloneBrowserControls` renders Refresh, Share and Open in Browser, and it is rendered only when `mobile && isChromelessDisplayMode()`. `ui/src/lib/pwa-display-mode.ts` exists for no other purpose than to detect `standalone`, `fullscreen` and `window-controls-overlay`. > - None of those modes can occur on a mobile launch while the manifest says `browser`, so that component and its fallback controls are unreachable in practice. > - That makes the manifest value look like the outlier rather than the intent, so the change is one manifest field plus the test that pins it. ## Linked Issues or Issue Description Refs #2139 — "enh: Officially support Install as Progressive Web App", which asks for a supported home-screen install. This pull request is the installability half of that request; it does not touch notifications. **Subsystem affected** The web app manifest and the unit test that guards it: `ui/public/site.webmanifest` and `ui/src/lib/pwa-install-mode.test.ts`. No server, plugin, or database code. **Problem or motivation** Chrome's installability criteria require `display` to be one of `fullscreen`, `standalone` or `minimal-ui`. With `display: "browser"` Chrome reports `manifest-display-not-supported`, offers only a shortcut, and the launch keeps browser controls, so the board never behaves like an installed application even though the manifest, service worker, and icons all exist. The same value also makes existing code unreachable: the in-app replacement controls for a chromeless launch (`StandaloneBrowserControls`, gated on `mobile && isChromelessDisplayMode()`) cannot be triggered from a mobile home-screen launch, so the app carries a fallback that nothing can exercise. **Proposed solution** - Set `display: "standalone"` in `ui/public/site.webmanifest`. - Update `ui/src/lib/pwa-install-mode.test.ts`, which asserted `display === "browser"`. The assertion now pins `standalone` and a comment records why, so the next reader does not have to reconstruct this reasoning. The assertions that keep the legacy `mobile-web-app-capable` and the Apple metas out of `index.html` are unchanged. `standalone` rather than `fullscreen` for two reasons. It keeps the Android status bar showing the clock and battery, and it avoids a known Android behaviour of `fullscreen` launches: opening the soft keyboard triggers a fullscreen transition and a visible flicker ([Google issue 392925620](https://issuetracker.google.com/issues/392925620), [Stack Overflow 71606355](https://stackoverflow.com/questions/71606355/pwa-does-not-resize-window-when-virtual-keyboard-is-active-on-fullscreen-display)), which `standalone` does not do. **Alternatives considered** - `fullscreen`. Also installable, and it additionally hides the Android status bar. Rejected as the default for that reason; it is a one-word change if preferred. - Adding the legacy `mobile-web-app-capable` meta. Rejected: Chrome reads the manifest, so the meta is redundant. - Adding the Apple `apple-mobile-web-app-capable` metas for iOS. Rejected for this change: it is iOS-specific, and iOS is not the platform whose installability check this fixes. - Changing `orientation`, which #5564 reports. Rejected as out of scope; this pull request stays on `display` only. **Roadmap alignment** `ROADMAP.md` does not plan this work. Its only mention of install is the skills store. **Additional context** - #7792 attempted a standalone PWA earlier and was closed during triage. It bundled a deploy-pipeline change and a heartbeat change with the manifest change, and its title carried an internal ticket id. This pull request is deliberately the manifest change alone. - #5564 reports that the manifest's `orientation: any` ignores the Android rotation lock. Related, not addressed here. - The keyboard flicker above was reported against a board installed with `fullscreen`, which is one of the two reasons this pull request asks for `standalone` instead of the more immersive mode. ## What Changed - `ui/public/site.webmanifest`: `display` is now `"standalone"` instead of `"browser"`. - `ui/src/lib/pwa-install-mode.test.ts`: the expectation that pinned `browser` now pins `standalone`, with the reasoning in a comment; the meta assertions are unchanged. No runtime code, no dependency, and no data change. The icons the installability check also requires (`android-chrome-192x192.png`, `android-chrome-512x512.png`) are already present and unchanged. ## Verification - `vitest run src/lib/pwa-install-mode.test.ts src/lib/pwa-display-mode.test.ts` in `ui`: 2 files, 7 tests passed (the same 2 + 5 the sibling plugin-event change reports). - The manifest parses as JSON, keeps `display: "standalone"`, and keeps 192 and 512 pixel icons. - The only place in the repository that asserts the manifest's `display` value is the test updated here; the other references to `site.webmanifest` are request routing and HTTP log policy and are unaffected. - CI on the previous head of this branch had two failures unrelated to this change: an e2e hover-opacity assertion on a sidebar star button (`Star Zeta`: expected `1`, received `0`) and `TypeError: Cannot read properties of undefined (reading 'logicalEffectCount')` in the runner verify job. Both are in subsystems this change cannot reach; CI is re-running on this commit. ## Risks - Low. One manifest field and one test expectation; no runtime code changes. - The value applies to new installations. An app already installed with the previous value keeps its installed configuration until it is reinstalled, so nobody loses a working install. - iOS launches are unchanged: Safari does not take `display` from the manifest for home-screen launches, and this change does not add the Apple metas. - Nobody depends on the address bar being present in an installed launch; the in-app controls that replace it (`StandaloneBrowserControls`) are already implemented and become reachable. ## Model Used - Provider: DeepSeek. Model ID: `deepseek-v4-flash`. The model ran as a tool-using coding agent (shell, file edits, headless browser automation) inside a coding harness. The harness did not report a context-window size or a reasoning mode. ## 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 issues and linked them above (#2139, #7792, #5564) - [x] I have either (a) linked existing issues with `Fixes:` / `Closes` / `Refs #` OR (b) described the issue in-PR following the relevant issue template — both, see above - [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 and contains no internal ticket id or instance-derived details - [x] I have run the affected tests locally and they pass (2 files, 7 tests) - [x] I have added or updated tests where applicable — the guard test is updated, and it is the only test that pins this value - [x] I have updated relevant documentation to reflect my changes — no user-facing document describes the manifest; the updated test now records the reasoning in place - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green — CI is re-running on this commit after the unrelated failures described under Verification - [ ] Greptile is 5/5 — awaiting the review run on this commit - [x] I will address all Greptile and reviewer comments before requesting merge
@paperclipai/ui
Published static assets for the Paperclip board UI.
What gets published
The npm package contains the production build under dist/. It does not ship the UI source tree or workspace-only dependencies.
Storybook
Storybook config, stories, and fixtures live under ui/storybook/.
pnpm --filter @paperclipai/ui storybook
pnpm --filter @paperclipai/ui build-storybook
Typical use
Install the package, then serve or copy the built files from node_modules/@paperclipai/ui/dist.
Editor dependency identity
Keep the root and workspace overrides for @codemirror/state,
@codemirror/view, and @lezer/common aligned. CodeMirror requires shared
extension identity, while Lezer parsers and syntax highlighters require shared
NodeProp IDs. Multiple Lezer copies can crash code-block highlighting with
tags is not iterable. src/lib/codemirror-single-instance.test.ts checks the
installed dependency graph and highlights sample code through the editor's real
language dependencies. GitHub Actions owns regeneration of pnpm-lock.yaml.