466a8c2340c99df94b50ec1891969057cb8ea56f
User reported (in Arabic, with screenshot) that the note Replies dialog was
covering the entire page when a thread had multiple grouped conversations.
The owner/admin grouped-replies view (`GroupedReplies`) had a `max-h-72`
internal scroll, but the outer `DialogContent` had no overall height cap, so
on tall content the dialog grew to fill the viewport.
Changes
- artifacts/tx-os/src/pages/notes.tsx
- `DialogContent` for the thread dialog: add `max-h-[85vh] flex flex-col`.
- Refactored body into three vertical zones (per code-review feedback):
1) static meta + recipient chips (`shrink-0`, always visible),
2) replies-only scroll region (`flex-1 min-h-0 overflow-y-auto`,
`data-testid="note-thread-scroll"`),
3) static composer (`shrink-0`, pinned at the bottom).
- Drop now-redundant `max-h-48` on the recipient ReplyBubble list and
`max-h-72` on `GroupedReplies` — the dedicated scroll zone handles
overflow, avoiding nested double scrollbars.
Tests
- New artifacts/tx-os/tests/notes-thread-dialog.spec.mjs:
- Seeds an owner note with 2 recipients and 30 alternating replies via
SQL, deep-links into `/notes?thread=ID`, asserts the dialog's bounding
box height ≤ 0.9 × viewport height, asserts the inner scroll region
actually overflows (scrollHeight > clientHeight), and asserts the
composer remains visible.
- Verified the existing notes-folders.spec.mjs (2 tests) still pass.
- `tsc --noEmit` clean.
Out of scope (left as-is): visual redesign, reply send/archive logic,
Inbox/Sent thread list.
Polish Services: Saudi Coffee rename + image, fix Black Coffee Arabic, hide order notes behind a button (Task #394)
Description
No description provided
Languages
TypeScript
69.4%
JavaScript
29%
CSS
0.6%
Shell
0.6%
Dockerfile
0.2%
Other
0.2%