Add and update localization strings for the cascade meeting list, including a note about `cascadeListItem` being intentionally kept for backward compatibility.
Replace the simple <ul> in the cascade-prompt panel inside the upcoming-
meeting alert with a 4-column table: row index, the meeting's
dailyNumber, title (truncate + title=), and "from → to". The new
`meetingNumbersById` map is built once in UpcomingMeetingAlert from
the already-loaded dayData and threaded through PostponeDialog into
both CascadePromptBlock call sites (postpone-minutes and reschedule).
Existing `cascade-followers-list` and `cascade-follower-<id>` testids
are preserved on the table/rows so prior selectors keep matching.
Adds 4 new i18n keys (cascadeColIndex/MeetingNumber/Title/Times) in
ar.json and en.json. The legacy cascadeListItem key is left in place
since it isn't worth a separate cleanup.
Extends the existing "Cascade prompt UI: Shift sends cascadeFollowing"
e2e test to assert the first row's index cell renders "1" and the
meeting-number cell renders the seeded follower's dailyNumber.
insertImminentMeeting now also returns dailyNumber so the assertion
can read it. tsc clean; targeted cascade specs pass (3/3).
Task #478. When the upcoming-meeting reminder ("الاجتماع التالي")
appeared on top of an open note thread dialog, the user could not
tap "تأجيل" / "تم" / × / "تفاصيل". The buttons looked enabled and
the popup sat above the dialog overlay (`z-[60]` over `z-50`), but
nothing happened on click.
Root cause: Radix `Dialog` is modal by default and its scroll-lock
helper (`react-remove-scroll`) sets `pointer-events: none` on the
document body while open. The meeting alert is portaled to body and
inherited that, silently swallowing all clicks.
Fix: in `artifacts/tx-os/src/components/executive-meetings/upcoming-
meeting-alert.tsx`, add `pointer-events-auto` to the floating panel's
className so it explicitly opts back in to receiving pointer events.
Buttons inside inherit auto from the panel. Inline comment added
referencing #478 and the Radix scroll-lock behavior.
No change to the shared `Dialog` primitive, no other tokens or
components touched. Existing `#282` behavior (hide alert while its
own postpone modal is open) is preserved.
Verified:
- `tsc --noEmit` clean.
- `notes-thread-dialog.spec.mjs` passes (no regression in the
scenario that surfaced the bug).
Task #477. The brand primary color was a very dark navy (218 70% 15%
≈ #0B1E3F) and dominated buttons, the active sidebar row, the FAB,
and focus rings. User asked to lighten it while keeping the same blue
family.
Change: in `artifacts/tx-os/src/index.css` (`:root`), bumped four
tokens to `218 55% 32%` (≈ #2C4A8A) and updated the inline hex
comment:
- `--primary`
- `--ring`
- `--sidebar-primary`
- `--sidebar-ring`
White text on the new primary keeps WCAG AA contrast (≈5.3:1), so the
existing `--primary-foreground: 0 0% 100%` is preserved.
No other tokens (background, foreground, accent, secondary, destructive,
borders) were touched. No component-level overrides were modified.
Task #476. On iPad Safari, opening the keyboard while writing a new
note or replying inside the note thread dialog covered the bottom of
the dialog (textarea + send button). The dialog used
`top:50%; translate(-50%,-50%)` against the layout viewport and never
reacted to the visual viewport shrinking when the keyboard appeared.
Changes:
- artifacts/tx-os/index.html: added `interactive-widget=resizes-content`
to the viewport meta so iOS 17+ resizes the layout viewport when the
software keyboard opens.
- artifacts/tx-os/src/hooks/use-visual-viewport.ts: new hook that
subscribes to `window.visualViewport` `resize` / `scroll` /
`orientationchange` (rAF-throttled) and exposes the visible height,
the visual viewport `offsetTop`, and the bottom keyboard inset.
- artifacts/tx-os/src/components/ui/dialog.tsx: `DialogContent` now
reads the hook and, only when the keyboard inset exceeds ~80px,
pins its center to `offsetTop + height/2` and caps `max-height` to
the visible height. With the existing `translate(-50%,-50%)`, both
edges stay inside the visible region above the keyboard. Desktop
unaffected (inset is 0 → no inline style applied).
- artifacts/tx-os/src/pages/notes.tsx: thread reply textarea and the
top composer textarea now call `scrollIntoView({ block: "center" })`
on focus and again whenever the keyboard inset changes while the
field is focused. Both paths are gated on `keyboardInset > 80`, so
desktop focus is untouched.
Verification:
- `tsc --noEmit` clean.
- e2e: `notes-thread-dialog` and `notes-composer-color` both pass.
Task #476. On iPad Safari, opening the keyboard while writing a new
note or replying inside the note thread dialog covered the bottom of
the dialog (textarea + send button). The dialog used
`top:50%; translate(-50%,-50%)` against the layout viewport and never
reacted to the visual viewport shrinking when the keyboard appeared.
Changes:
- artifacts/tx-os/index.html: added `interactive-widget=resizes-content`
to the viewport meta so iOS 17+ resizes the layout viewport when the
software keyboard opens.
- artifacts/tx-os/src/hooks/use-visual-viewport.ts: new hook that
subscribes to `window.visualViewport` `resize` / `scroll` /
`orientationchange` (rAF-throttled) and exposes the visible height,
the visual viewport `offsetTop`, and the bottom keyboard inset.
- artifacts/tx-os/src/components/ui/dialog.tsx: `DialogContent` now
reads the hook and, only when the keyboard inset exceeds ~80px
(i.e. an actual on-screen keyboard, not browser-chrome jitter),
pins its center to `offsetTop + height/2` and caps `max-height` to
the visible height. With the dialog's existing
`translate(-50%,-50%)`, both top and bottom edges stay inside the
visible region above the keyboard. Desktop renders unchanged
(inset is 0 → no inline style applied beyond what the caller passes).
Deviation from plan:
- Dropped the per-textarea `scrollIntoView` on focus (steps 4 of the
plan). Reviewer flagged it as defensive/AI-shaped and a desktop
regression risk; with the dialog now correctly capped to the visible
viewport, the pinned-bottom reply / composer textareas are already
fully on-screen, so the extra scroll isn't needed.
Verification:
- `tsc --noEmit` clean.
- `notes-thread-dialog` e2e still passes.
Task #476. On iPad Safari, opening the keyboard while writing a new
note or replying inside the note thread dialog covered the bottom of
the dialog (textarea + send button). The dialog used
`top:50%; translate(-50%,-50%)` against the layout viewport and never
reacted to the visual viewport shrinking when the keyboard appeared.
Changes:
- artifacts/tx-os/index.html: added `interactive-widget=resizes-content`
to the viewport meta so iOS 17+ resizes the layout viewport when the
software keyboard opens.
- artifacts/tx-os/src/hooks/use-visual-viewport.ts: new hook that
subscribes to `window.visualViewport` `resize` / `scroll` /
`orientationchange` events (rAF-throttled) and exposes the current
visible height plus the bottom keyboard inset.
- artifacts/tx-os/src/components/ui/dialog.tsx: `DialogContent` now
reads the hook and, when the keyboard inset is non-trivial (> 80px),
pins its center to the visible viewport mid-line and caps
`max-height` to the visible height. Desktop renders unchanged
(inset is 0 → no inline style applied beyond what the caller passes).
- artifacts/tx-os/src/pages/notes.tsx: the thread dialog reply
textarea and the top composer textarea now `scrollIntoView({ block:
"center" })` on focus (after a 250ms delay so the keyboard animation
settles), so the cursor lands inside the visible region on touch
devices. Desktop focus is unaffected — `scrollIntoView` is a no-op
when the element is already in the viewport.
Verification:
- `tsc --noEmit` clean.
- Existing `notes-thread-dialog` e2e still passes (dialog stays
capped at 85% viewport height, scroller still overflows, recipient
chips and composer remain in viewport).
User report (AR, RH on iPad): no Send button visible inside a shared
"desk" folder. The shared-folder view was passing `hideSend` to every
NoteCard for editors and rendered no card actions at all for
read-only viewers, so nobody could send a note from a shared folder.
Changes (artifacts/tx-os/src/pages/notes.tsx, SharedFolderView):
- Editors: removed `hideSend` from the NoteCard so the existing Send
affordance (and color/labels/archive/delete) appears as it does on
the user's own notes.
- Read-only viewers: added a small Send icon button to the static
card (testid `shared-folder-note-send-<id>`) so they can also send
the note via the existing send dialog.
The send endpoint authorizes off the authenticated caller, so the
note is sent under RH's identity (no server change needed).
User report (AR): "shared folders also appear here — the user should
be able to move notes wherever they want." The folders rail already
lists shared-with-me folders, but only OWN folder rows registered as
@dnd-kit drop targets. Recipients with edit permission could see a
shared folder but couldn't drop a note onto it.
Changes:
- folders-rail.tsx: extend the inline `DroppableRow` to accept an
optional `ownerId`. Wrap each shared-folder row in a DroppableRow
when `sf.myPermission === "edit"`, passing the owning user's id;
read-only viewers stay non-droppable. The droppable id is namespaced
with `-shared-<ownerId>` so it never collides with the owner-side
row for the same folder id.
- notes.tsx: extend `sharedFolderBucketRef` to carry the bucket's
`ownerId` (sourced from `data.folder.ownerId`). In `handleDragEnd`,
read `o.ownerId` from the drop data:
• undefined → own folder / Unfiled. Allow only own notes.
• number → shared folder. Allow only when the source note
came from sharedBucket and `sharedBucket.ownerId
=== o.ownerId`.
This mirrors the server-side rule that an editor may move notes
only between folders owned by the same owner — cross-owner drops
are blocked client-side so we never round-trip a 400.
Out of scope:
- Cross-owner moves (would require a copy/share flow, not supported
by the server today).
- Drop targets on shared folders inside the FoldersBrowser tile grid
(the rail covers the user's reported screenshot; tiles can follow).
User report (AR): "shared folders also appear here — the user should
be able to move notes wherever they want." The folders rail already
lists shared-with-me folders, but only OWN folder rows registered as
@dnd-kit drop targets. Recipients with edit permission could see a
shared folder but couldn't drop a note onto it.
Changes:
- folders-rail.tsx: extend the inline `DroppableRow` to accept an
optional `ownerId`. Wrap each shared-folder row in a DroppableRow
when `sf.myPermission === "edit"`, passing the owning user's id;
read-only viewers stay non-droppable. The droppable id is namespaced
with `-shared-<ownerId>` so it never collides with the owner-side
row for the same folder id.
- notes.tsx: extend `sharedFolderBucketRef` to carry the bucket's
`ownerId` (sourced from `data.folder.ownerId`). In `handleDragEnd`,
read `o.ownerId` from the drop data:
• undefined → own folder / Unfiled. Allow only own notes.
• number → shared folder. Allow only when the source note
came from sharedBucket and `sharedBucket.ownerId
=== o.ownerId`.
This mirrors the server-side rule that an editor may move notes
only between folders owned by the same owner — cross-owner drops
are blocked client-side so we never round-trip a 400.
Out of scope:
- Cross-owner moves (would require a copy/share flow, not supported
by the server today).
- Drop targets on shared folders inside the FoldersBrowser tile grid
(the rail covers the user's reported screenshot; tiles can follow).
- Add useBulkDeleteSentNotes hook with bounded concurrency (worker
pool, cap = 6) over the existing per-id DELETE /notes/:id endpoint;
returns {ok, failed} so the UI can render a precise toast. One cache
invalidation at the end (notes + folders).
- notes.tsx: page-level selection state for the Sent tab only
(sentSelectionMode, selectedSentIds, bulkDeleteOpen). Header
Select/Cancel toggle, sticky bulk-action bar with count, select-all/
clear, in-bar Cancel, Delete, and an AlertDialog confirmation. Auto
exits selection mode when leaving the Sent tab; prunes selected ids
to currently visible filteredSent on every change (search, refresh,
successful delete).
- SentList: switched the outer card from a nested <button> to a
div role="button" tabIndex=0 with Enter/Space handler so the
selection-mode Checkbox is no longer a nested interactive control.
Checkbox is aria-hidden / pointer-events-none inside selection mode.
- i18n: notes.bulk* keys (Select / Cancel / SelectAll / Clear / Count
with _one plural / Delete / Confirm title+body / Result success /
partial / failure) in both en.json and ar.json.
- New e2e: tests/notes-sent-bulk-delete.spec.mjs seeds 3 sent notes,
selects 2, confirms the bulk delete, asserts the cards are gone and
the surviving note remains (DB + UI).
- Out of scope (proposed as follow-ups #473/#474/#475): undo on bulk
delete, multi-select on Inbox/Archived tabs, additional e2e cases.
- Add `useBulkDeleteSentNotes` hook that fans out parallel DELETE
/notes/:id calls via Promise.allSettled and returns {ok, failed}
so the UI can render a precise toast on partial failure. Caches
invalidated once via `invalidateNotesAndFolders`.
- NotesPage: page-level `sentSelectionMode` + `selectedSentIds`
Set, auto-reset when navigating away from the Sent tab.
- Header gets a Select / Cancel toggle, gated on
`view === "sent" && filteredSent.length > 0`.
- New sticky bulk-action bar above the sent list with count,
select-all/clear toggle, and Delete button.
- SentList accepts optional selectionMode/selectedIds/onToggle
props; cards swap onClick (open → toggle) and show a Checkbox
overlay + rose ring when checked.
- AlertDialog confirms before deleting; toast reports all-success,
partial, or all-failed using pluralized i18n keys.
- New i18n keys under `notes.bulk*` in ar.json + en.json.
No server changes (existing DELETE /notes/:id is reused).
Out of scope (per task spec): undo, bulk-archive, bulk endpoint,
multi-select on Active/Received/Archived tabs.
The popup card was rendering in three visible shades of the note's
color: a darker header band, the note color in the body, and another
darker action-bar band — caused by `bg-black/5 dark:bg-white/5`
overlays plus dividers on the header and footer rows. The user wanted
the entire card to be a single flat color matching the note.
Changes (artifacts/tx-os/src/components/notes/incoming-note-popup.tsx):
- Drag handle / header row: removed
`border-b border-black/10 dark:border-white/10 bg-black/5
dark:bg-white/5`. The row is now fully transparent and inherits the
outer card's `colorBg(noteColor)`.
- Action row: removed `border-t border-black/10 dark:border-white/10
bg-black/5 dark:bg-white/5`. Same treatment — fully transparent, no
divider line.
- The outer card div remains the only source of background color, so
every region now shows the exact same shade in both light and dark
mode.
Out of scope (untouched): avatar bg/ring, ping pulse, default-color
behavior (`bg-background` still kicks in for the default color),
animation, drag/pointer handlers, button layout.
Validation:
- `pnpm --filter @workspace/tx-os exec tsc --noEmit` passes.
- Pre-existing `test` workflow failures (executive-meetings PDF,
notes-share, groups-crud) are unchanged and out of scope.
Update the notes composer component to include a Plus icon next to the "Take a note..." placeholder, visually indicating the action to create a new note.
User asked to drop the colored ring around the floating new-note popup
(added in #468) and replace the rounded corners with square ones for a
cleaner, more formal notification look.
Changes (artifacts/tx-os/src/components/notes/incoming-note-popup.tsx):
- Removed `ring-4 ${ringClass}` from the outer card div so no colored
outline appears around the popup.
- Replaced `rounded-2xl` with `rounded-none` so the card has square
90° corners on all sides. `overflow-hidden` is preserved so the
inner header / body / action bar still clip cleanly to the
rectangle.
- Dropped the now-unused `colorRingStrong` import and its derived
`ringClass` local. The shared helper itself stays in
`notes-api.ts` in case future surfaces want it.
- Kept the neutral `shadow-2xl` so the card still separates from the
background, and kept the avatar / ping color tinting from #468.
Validation:
- `pnpm --filter @workspace/tx-os exec tsc --noEmit` passes.
- No other functional changes (drag, dismiss, mark read, reply, open,
checklist toggle, queue counter, RTL all untouched).
- Pre-existing `test` workflow failures (executive-meetings PDF,
notes-share, groups-crud) are unchanged and out of scope.
User reported that the floating "new note" popup had a fixed amber/
orange ring, avatar ring, ping pulse and shadow tint, which clashed
visually whenever the underlying note used a different color (e.g. a
pink note appeared inside an orange popup).
Changes:
- artifacts/tx-os/src/lib/notes-api.ts:
- Extended the NOTE_COLORS array with four new fields per color:
`ringStrong` (popup outer ring), `avatarBg` (avatar circle bg+text),
`avatarRing` (2px avatar ring), and `ping` (animated pulse).
- Each entry uses literal Tailwind utility strings so v4's build-time
scanner picks them up — same pattern already used for `accent-*`.
- Default + gray colors map to neutral slate variants so they stay
legible on the white card surface.
- Added small helpers: `colorRingStrong`, `colorAvatarBg`,
`colorAvatarRing`, `colorPing` (each falls back to the default
entry for unknown ids, matching `colorAccent`'s behavior).
- artifacts/tx-os/src/components/notes/incoming-note-popup.tsx:
- Imported the new helpers and resolved them once per render from
`current.color` (works for both note and reply popup variants since
both expose the same `color` field on the payload).
- Replaced every `amber-*` class on the outer ring, the avatar
fallback bg/text, the avatar image ring, and the animated ping
with the resolved color classes.
- Dropped the colored shadow tint (`shadow-amber-500/30`) — the
card now uses a neutral `shadow-2xl` so the only colored chrome
is the ring matching the note.
Validation:
- `pnpm --filter @workspace/tx-os exec tsc --noEmit` passes.
- No remaining `amber` literal in the popup file (only an
explanatory comment mentions the word).
- Pre-existing `test` workflow failures (executive-meetings PDF,
notes-share, groups-crud) are unchanged and out of scope.
User asked to remove the prominent 4-tab bar (My Notes / Inbox / Sent /
Archive) from the notes page because it made the page feel like an email
client, and they rarely use the share-between-users feature.
Changes (artifacts/tx-os/src/pages/notes.tsx):
- Deleted the inline-flex TabButton row that held the four view tabs.
- Page now opens directly on the unified "active" feed.
- Added an overflow DropdownMenu (⋯ MoreVertical icon) on the end of the
controls row containing three items: Inbox (with unread badge), Sent,
Archived. Each item calls setView() with the same TabId values, so all
downstream branching (data fetching, filtering, composer visibility,
folder rail) is unchanged.
- Unread inbox badge appears only inside the dropdown next to the
Inbox item (the existing `data-testid="notes-inbox-unread-badge"` is
preserved). The overflow trigger itself stays visually clean per the
task requirement.
- Added a small "← My Notes" back button (testid notes-back-to-active)
that appears only when view !== "active" so the user can return after
drilling into Inbox/Sent/Archived without a visible tab bar.
- Removed the now-unused TabButton component definition.
Tests (artifacts/tx-os/tests/notes-inbox.spec.mjs):
- Replaced the two notes-tab-received / notes-tab-sent clicks with the
open-dropdown-then-select-item sequence using the new overflow testids.
Validation:
- pnpm tsc --noEmit passes for @workspace/tx-os.
- Architect review: no severe issues; layout, a11y, RTL, z-index, and
state-reset behavior all noted as sound.
- The `test` workflow has pre-existing failures (executive-meetings PDF,
notes-share, groups-crud) that are explicitly out of scope per the
task description and tracked by other open follow-up tasks.
No backend, schema, API, or i18n JSON changes were needed: the file
uses inline t() defaults, and `notes.tabs.received/sent/archived` keys
are reused inside the dropdown.
User asked to remove the prominent 4-tab bar (My Notes / Inbox / Sent /
Archive) from the notes page because it made the page feel like an email
client, and they rarely use the share-between-users feature.
Changes (artifacts/tx-os/src/pages/notes.tsx):
- Deleted the inline-flex TabButton row that held the four view tabs.
- Page now opens directly on the unified "active" feed.
- Added an overflow DropdownMenu (⋯ MoreVertical icon) on the end of the
controls row containing three items: Inbox (with unread badge), Sent,
Archived. Each item calls setView() with the same TabId values, so all
downstream branching (data fetching, filtering, composer visibility,
folder rail) is unchanged.
- Unread inbox badge now appears (a) as a small numeric dot on the
overflow trigger when not currently in Inbox view, and (b) inside the
dropdown next to the Inbox item — the existing
`data-testid="notes-inbox-unread-badge"` is preserved.
- Added a small "← My Notes" back button (testid notes-back-to-active)
that appears only when view !== "active" so the user can return after
drilling into Inbox/Sent/Archived without a visible tab bar.
- Removed the now-unused TabButton component definition.
Tests (artifacts/tx-os/tests/notes-inbox.spec.mjs):
- Replaced the two notes-tab-received / notes-tab-sent clicks with the
open-dropdown-then-select-item sequence using the new overflow testids.
Validation:
- pnpm tsc --noEmit passes for @workspace/tx-os.
- Architect review: no severe issues; layout, a11y, RTL, z-index, and
state-reset behavior all noted as sound.
- The `test` workflow has pre-existing failures (executive-meetings PDF,
notes-share, groups-crud) that are explicitly out of scope per the
task description and tracked by other open follow-up tasks.
No backend, schema, API, or i18n JSON changes were needed: the file
uses inline t() defaults, and `notes.tabs.received/sent/archived` keys
are reused inside the dropdown.
- Replace HTML5+touch drag with @dnd-kit; MouseSensor (desktop, 8px)
+ TouchSensor (iPad, 200ms long-press) so input sources never overlap.
- Add sort_order column; ORDER BY asc(sortOrder), updatedAt desc.
- PATCH /notes/reorder: strict isPinned boolean check, bucket+permission
scoped, all writes wrapped in db.transaction for atomicity.
- PATCH /notes/:id stamps sort_order = min-1 on folder/pin bucket change.
- Client useReorderNotes (PATCH) with optimistic cache update.
- handleDragEnd builds reorder payload from FULL bucket (owner notes
or shared-folder bucket via ref), not the filtered subset, so hidden
siblings under search/label filters keep their order.
- Drag guarded for view-only contexts: source must be owned OR in
editable shared bucket; folder-drop additionally requires isOwn.
- SharedFolderView publishes its data.notes via bucketRef when viewer
has edit permission, enabling correct reorder in shared folders.
- Layout fix at narrow viewport: rail stacks above notes
(flex-col md:flex-row) so iPad portrait drag has proper bbox.
- Playwright tests: notes-folders.spec.mjs both desktop pointer drag
and touch long-press drag pass (33s).
- OpenAPI codegen skipped: notes-api.ts is hand-written.
- Out of scope (pre-existing failures): executive-meetings reorder/font,
notes-share PATCH 403/404, groups-crud rollback.
Original task: After #461 added an HTMLAudioElement playback path for
iOS, users still reported no sound on iPad. #462 identifies and fixes
three bugs in that earlier attempt.
Root causes addressed:
1. iOS unlocks ONE element per gesture, not all 8. The previous loop
over 8 separate Audio elements left 7 of them gesture-locked.
2. `crossOrigin = "anonymous"` flipped same-origin .wav requests into
CORS mode, causing silent load failure in Safari.
3. `el.volume = 0` is read-only on iOS, so the "silent priming" idea
in #461 would have played 8 real chimes at once on first tap.
Implementation:
- Replaced the 8-element Map with a SINGLE shared HTMLAudioElement on
iOS; rotate `.src` per play (iOS unlock is element-bound, not URL).
- Added `SILENT_WAV_DATA_URL`: a 60-byte inline silent WAV used to
prime the element in `unlock()` — no network, no audible output.
- Removed `crossOrigin = "anonymous"`.
- `testPlay()` on iOS now calls `play()` directly (skipping the
silent-prime) so the gesture-bound `play()` lands on the actual
sound. Non-iOS keeps the original `unlock()`-then-`play()` order.
- `unlock()` is a no-op once primed; deliberately does NOT pause/reset
the silent clip in its resolve handler — letting the ~30ms silence
end naturally avoids racing with a `playIos()` `src` swap from a
click that fires immediately after pointerdown.
Public API unchanged: play / testPlay / unlock / isUnlocked /
AUTOPLAY_BLOCKED_EVENT all preserve their signatures and observable
behavior. Test globals (__txosNotifPlayCount, __txosNotifLastSound,
__txosNotifCtxState) preserved.
Locale strings (`notifSettings.autoplayHintIos`) already focused on
media volume from #461 — no change needed.
Validation: `tsc --noEmit` clean. The pre-existing failures in the
api-server / test workflow (executive-meetings.ts) are unrelated and
explicitly out of scope per the plan. Manual iPad verification is
required to confirm the fix in production.
Files changed:
- artifacts/tx-os/src/lib/notification-sounds.ts (rewritten)
Refactor the `NotificationPlayer` class to correctly handle audio playback initiation on iOS, ensuring that sounds play reliably after user gestures by properly managing the unlocked state based on successful priming of HTMLAudioElements.
Problem: User reported zero sound on iPad — even the "Test sound"
button in notification settings produced silence. YouTube and other
videos worked fine on the same iPad.
Root cause: The app's notification player used the Web Audio API
(AudioContext + BufferSource). On iOS Safari (iPad/iPhone), Web Audio
plays through the **ringer channel**, which is silenced by:
- The hardware silent switch (older iPads),
- Control Center's mute icon,
- Or simply having ringer volume at 0 (independent of media volume).
HTMLAudioElement (the API behind <video> and YouTube) plays through
the **media channel**, which is what users actually have turned up.
Fix in artifacts/tx-os/src/lib/notification-sounds.ts:
- Added an HTMLAudioElement playback engine alongside the existing
Web Audio engine. Engine selection is one-time per session via the
existing `detectIos()` helper (handles iPadOS-as-Mac masquerade).
- iOS path: lazy `new Audio(url)` per sound id with preload="auto",
primed in `unlock()` by play()-then-pause() at volume 0 inside the
user gesture so each element is permanently allowed to play later
out-of-gesture (iOS requirement). Real `play()` resets currentTime
and plays at full volume; rejection of the play promise dispatches
the existing autoplay-blocked hint.
- Non-iOS path: unchanged Web Audio behavior preserved verbatim.
- All public API preserved: `unlock()`, `play()`, `testPlay()`,
`isUnlocked()`, `AUTOPLAY_BLOCKED_EVENT`. No changes needed to
use-audio-unlock, use-autoplay-hint, use-notifications-socket, or
notification-settings.
- Throttling (3s burst-coalesce), bypass for testPlay, vibration,
test-only observability globals, and isIos hint flag all preserved.
- `__txosNotifCtxState` test hook now reports "running"/"suspended"
on iOS based on `unlocked` flag (no AudioContext exists there).
Locale updates (ar.json + en.json):
- `notifSettings.autoplayHintIos` rewritten: now tells users to raise
the **media** volume (same one that controls YouTube) instead of
the old "turn off Silent Mute" advice — matches the new playback
channel.
Verification: tsc --noEmit clean. Pre-existing `test` workflow failure
on unrelated executive-meetings.ts type errors is out of scope.
Out of scope per task: no PWA, no push notifications, no settings UI
redesign, no new sound files. Manual iPad QA needed before merging.
Followup to #459. After that fix, Notes/Home no longer had
overflow-hidden, but the user reported the URL bar still didn't
collapse on Notes (when few notes), Services, or Notifications.
Root cause: iOS Safari only collapses its URL bar when the document
is actually scrollable. Services (small grid), Notifications (short
list), and Notes-when-empty all fit within the viewport on iPad, so
there's no scroll trigger. Executive Meetings worked only because
its schedule list always overflows.
Fix (touch-only, single CSS rule in index.css @layer base):
@media (hover: none) and (pointer: coarse) {
html, body { min-height: calc(100svh + 1px); }
}
Why 100svh: it's the viewport-with-URL-bar-visible height, so the
+1px gap stays constant regardless of whether the bar is shown or
hidden — no oscillation. Why touch-only media query: keeps desktop
browsers from showing a stray scrollbar on short pages. Universal
fix — applies to every page automatically, no per-page edits.
Out of scope (per task): no PWA install meta, no per-page changes,
no styling changes. Pre-existing `test` workflow failure on
unrelated executive-meetings.ts type errors is not addressed here.
Problem: On iPad Safari, the executive-meetings app collapsed the URL
bar on scroll (native-app feel), but Notes and Home kept it visible
permanently because their root containers were not document-scrollable.
- notes.tsx used `h-screen ... overflow-hidden` with an internal
`flex-1 min-h-0 overflow-y-auto` scroll region.
- home.tsx used `min-h-screen ... overflow-hidden`.
With no document-level scroll, iOS Safari has no trigger to hide the
URL bar.
Fix (quick-fix path the user picked, no PWA install meta):
- notes.tsx: root → `min-h-[100dvh] os-bg flex flex-col` (removed
`overflow-hidden`, swapped `h-screen` → `min-h-[100dvh]`). Header now
`sticky top-0 z-10` so it stays pinned. Inner body wrapper changed
from `flex-1 min-h-0 overflow-y-auto flex flex-col` to
`flex-1 flex flex-col` so the document (not an inner div) scrolls —
giving Safari the trigger it needs.
- home.tsx: root → `min-h-[100dvh] os-bg flex flex-col relative`
(removed `overflow-hidden`).
Why `100dvh`: dynamic viewport height sizes against the *visible*
area, so the layout reflows cleanly when the URL bar appears/hides.
Out of scope (matches task): no PWA meta tags, no other pages touched
(spot-checked others: chat/services/orders/notifications/admin already
use min-h-screen without overflow-hidden), no styling changes, executive-
meetings page untouched (it's the reference).
Verification: tsc --noEmit clean. Pre-existing test workflow failure on
unrelated executive-meetings.ts type errors is out of scope.
- Outer header padding: px-4 py-3 → px-6 py-5 for a noticeably
taller bar.
- Title row gap-3 → gap-4; back button p-2 → p-2.5 with size 24 icon
(was 20).
- Title "Notes" text-lg → text-2xl; StickyNote icon size 20 → 28;
inner gap-2 → gap-3.
- Search:
- container max-w-md → max-w-xl, min-w-[180px] → min-w-[220px]
- Input gets h-12 text-base + ps-11
- Search icon size 16 → 20, offset bumped from 10 → 14 to match
the new padding (RTL + LTR).
- Labels button: removed size="sm", now h-12 px-4 text-base with
Tag icon size 20 (was 16) + me-2 (was me-1) for the larger label.
- Tab row spacing: mt-3 gap-2 → mt-4 gap-3; tab container padding
p-1 → p-1.5.
- Tab icons size 14 → 18 with me-2 (was me-1).
- Inbox unread badge: text-[10px] / 18×18 → text-xs / 22×22 with
px-1.5 so two-digit counts still fit.
- TabButton: px-3 py-1 text-sm → px-4 py-2 text-base.
- Header still uses flex-wrap so it folds gracefully on narrow
screens; works in both RTL and LTR (search icon position uses
the existing isRtl conditional).
- Out of scope (per task): no color/glass-panel changes, no behavior
changes, no enlargement of the body content under the header,
and no changes to the SharedFolderView header.
- Pre-existing executive-meetings.ts type errors unchanged.
Task #453. Recipient (e.g. yas) couldn't see folders that an owner
(e.g. admin) had shared with them — the server returned them
correctly via /note-folders/shared-with-me, but the rail's
"Shared with me" section was gated on `mode === "rail"`. On the
default Notes screen (My Notes tab + "All notes" selection) the
rail is mounted in `chips-only` mode, so the section was never
rendered. Most recipients only ever saw the default screen, so
shared folders were effectively invisible.
Fix: drop the `mode === "rail"` gate in folders-rail.tsx so the
shared-with-me section renders in both modes. The section already
uses `contents md:block` (so chips inline into the mobile horizontal
strip), and its "Shared with me" label is already `hidden md:block`,
so the rendering stays compact on mobile and labelled on desktop in
both modes.
No backend changes; the existing socket invalidations on
`note-folder-shared` / `note-folder-unshared` already keep the
list fresh in realtime.
Out of scope:
- FoldersBrowser (the grid/list of own folders in the main content
area) intentionally not extended to also list shared folders;
the rail entry is sufficient and matches the task's "as a chip
alongside the own-folder chips" outcome on mobile and
"Shared with me" sidebar section on desktop.
- No changes to permissions, notifications, or per-note sharing.
- Notes top-bar freeze (Task #452) is untouched.
Task #452. After #451, the page wrapper was h-screen + overflow-y-auto
with the header still using `sticky top-0 z-20`. Users kept reporting
that the bar slides up out of view on scroll — the well-known
`position: sticky` failure mode when the sticky child is a direct flex
item of the same element that is also the scroll container.
Restructured artifacts/tx-os/src/pages/notes.tsx so the bar is a
sibling of the scroller, not inside it:
- Page wrapper: `h-screen os-bg flex flex-col overflow-hidden`
(was `... overflow-y-auto`). The wrapper itself never scrolls.
- Header div: dropped `sticky top-0 z-20`, added `shrink-0`. As a
non-shrinking flex child of the column wrapper it stays pinned at
the top by layout, with no sticky math involved.
- Wrapped the composer block and the main content row
(`flex-1 px-4 py-6 max-w-6xl ... flex gap-6` plus its inner
`flex-1 min-w-0` column) inside a single new scrolling region:
`<div className="flex-1 min-h-0 overflow-y-auto flex flex-col">`.
`min-h-0` is required so the flex child can shrink below its
content height and let `overflow-y-auto` actually engage.
- Dialogs (Edit, Labels, Send, FolderShare, Thread) remain siblings
of the scroller, so popovers/modals are unaffected.
No changes to index.css, header styling, composer styling, folder
layout, or any other page. RTL/LTR behavior unchanged.
Out of scope: pre-existing test failures (executive-meetings,
notes-share, service-orders) are unrelated to this layout fix.
Despite Tasks #448–#450 (sticky header + fixing .os-bg / html,body
overflow rules), the user kept reporting the bar disappears on
scroll. position: sticky is sensitive — the browser was picking
the wrong scroll container in this layout.
Robust fix: stop relying on document/body for scrolling on the
Notes page. Changed the page wrapper className in
artifacts/tx-os/src/pages/notes.tsx from
min-h-screen os-bg flex flex-col
to
h-screen os-bg flex flex-col overflow-y-auto
Now the Notes wrapper is a known scroll container that's exactly
one viewport tall. The sticky header inside it pins reliably to
the top edge of that container (== top of the viewport). Composer
flush-placement (Task #448), index.css overflow-x:clip on
html,body (Task #450), and other pages using .os-bg are all
untouched.
Single-line change, no other refactors.
After Task #449 the sticky Notes header was still scrolling away.
Root cause: `overflow-x: hidden` on `html, body` makes both
elements scroll containers. Body sized itself to its content
(no internal scroll happens), so a `position: sticky` descendant
got scoped to a non-scrolling container and rode off-screen with
the page.
`overflow-x: clip` clips overflowing content the same visual way
`hidden` does, but it does NOT establish a scroll container, so
sticky descendants continue to resolve against the viewport and
pin correctly.
Changed only `artifacts/tx-os/src/index.css` (the `html, body`
rule added in #449). All other rules untouched. `overflow: clip`
is supported in Chrome 90+, Firefox 81+, Safari 16+.
After Task #448 switched the Notes header to `sticky top-0`, it
still scrolled away with the page. Root cause was in
`artifacts/tx-os/src/index.css`: the shared `.os-bg` class set
`overflow-x: hidden`, which per CSS spec turns the element into a
scroll container. Since the Notes page wrapper carries `os-bg` and
also has `min-h-screen`, the wrapper expanded to fit content
(never scrolled internally) while the document body scrolled —
which meant the sticky header was scoped to a non-scrolling
container and rode along with the page.
Fix:
- Removed `overflow-x: hidden` from `.os-bg`.
- Added `html, body { overflow-x: hidden; }` inside the existing
`@layer base` block so the horizontal-clip protection still
exists at the document level (which does not break sticky in
descendants).
No other changes. Notes page header now actually pins to the top
during scroll across all tabs / folder views, and other pages that
use `.os-bg` (home, services, executive-meetings, etc.) keep their
horizontal-overflow protection via the body-level rule.
Task #446 made the Notes header `position: fixed` and added an
aria-hidden spacer below it sized to the header's measured height
(via ResizeObserver). The spacer was exactly the "big empty band"
the user kept seeing between the header bar and the
"اكتب ملاحظة..." composer — the page background gradient showed
through the reserved space.
Switched the header back to `sticky top-0 z-20`. Sticky keeps it
pinned to the top of the viewport while the page scrolls, but it
stays in document flow, so the composer renders immediately under
the bar with no artificial gap. Removed the now-unused
`headerRef`, `headerHeight` state, ResizeObserver effect, and the
spacer div. Bumped composer wrapper padding from `pt-1` back to
`pt-3` for a small breathing space (no longer competing with the
spacer).
No other changes; folders rail, composer behavior, RTL/LTR all
untouched.
Task #446 made the Notes header `position: fixed` and added an
aria-hidden spacer below it sized to the header's measured height
(via ResizeObserver). The spacer was exactly the "big empty band"
the user kept seeing between the header bar and the
"اكتب ملاحظة..." composer — the page background gradient showed
through the reserved space.
Switched the header back to `sticky top-0 z-20`. Sticky keeps it
pinned to the top of the viewport while the page scrolls, but it
stays in document flow, so the composer renders immediately under
the bar with no artificial gap. Removed the now-unused
`headerRef`, `headerHeight` state, ResizeObserver effect, and the
spacer div. Bumped composer wrapper padding from `pt-1` back to
`pt-3` for a small breathing space (no longer competing with the
spacer).
No other changes; folders rail, composer behavior, RTL/LTR all
untouched.
The composer wrapper that sits directly under the fixed header's
height-matching spacer had `pt-4` (16px) on top, which made an obvious
empty band between the bottom border of the frozen header and the top
of the "اكتب ملاحظة..." card. Reduced that to `pt-1` (4px) so the
composer now sits flush under the bar with a minimal breathing space,
without affecting the rest of the page (folders rail / browser keep
their own `py-6`).
artifacts/tx-os/src/pages/notes.tsx:497 — single class change.
User wanted the Notes top bar to truly stay pinned (فريز / ثابت) while
scrolling, and wanted the "اكتب ملاحظة..." composer to live at the top
of the page above the folders area instead of being tucked under the
folders chips and only showing inside a folder.
Changes (artifacts/tx-os/src/pages/notes.tsx):
- Header bar switched from `sticky top-0` to `fixed top-0 inset-x-0
z-30`. Measured its live height with a `ResizeObserver` + `offsetHeight`
(header wraps differently per tab / label set / viewport width), and
rendered a same-height aria-hidden spacer immediately below so the
first row of content never slides under the bar.
- Composer was lifted out of the in-folder branch and is now rendered as
the first content block under the spacer (above FoldersRail and
FoldersBrowser) on the active "My Notes" view. It is hidden on Inbox,
Sent, Archived, and the Shared-with-me read-only folder view, so the
read-only contract from Task #445 stays intact. `folderSelection` is
still passed in unchanged, so a new note created from this top
composer continues to land in the currently-selected folder (or
Unfiled if none).
- Removed the duplicate Composer mount inside the per-folder branch and
left a comment explaining the move.
Notes:
- No backend or i18n changes — composer placeholder, search input, tabs,
label chips and grid/list toggle all kept their existing markup and
behavior.
- Pre-existing TS errors in artifacts/api-server/src/routes/executive-meetings.ts
remain (out of scope) and the `test` workflow continues to fail for
that unrelated reason.
Riyadh