fix(ui): hold info toast ~1s before it rises and fades #181

Merged

developer merged 1 commits from feature/toast-hold-before-fade into development 2026-07-05 12:24:08 +00:00

Conversation 1 Commits 1 Files Changed 2

+16 -13

developer commented 2026-07-05 12:10:57 +00:00

Owner

Copy Link

Copy Source

Third in a linear stack: #179 → #180 → this (branched off #180). Until those merge, this PR's diff also shows their commits c1805e5/fb7490f; review the top commit 400b6ac (only Toast.svelte + app.svelte.ts). No file overlap with #179/#180 — stacked only to keep the test contour coherent. Merge #179 → #180 → this.

What

The info toast began drifting up and fading the instant it finished appearing (the CSS keyframes jumped from the 12% appeared-stop straight to the 100% risen-and-faded stop), so a glanced message was already leaving.

Change

Insert a ~1s hold at rest before the rise-and-fade:

• Toast.svelte: animation 2s → 3s, keyframe stops at 8% (appeared, ~240ms) and 41% (end of the ~1s hold); the rise-and-fade tail keeps its original pace. Reduced-motion variant gets the same appear/hold/fade timing (fade only, no travel).
• app.svelte.ts: showToast dismissal timer 2000 → 3000ms, in lockstep with the animation. The error toast (4s dwell, Svelte fly/fade) is unchanged.

Cosmetic animation-timing only — no logic branch and no non-brittle test layer for it (an e2e timing assertion would be flaky), so no test added; eyeball on the contour.

Verification (local)

• pnpm check — 0 / 0
• pnpm test:unit — 396 passed
• pnpm test:e2e — 190 passed (Chromium + WebKit) — confirms the 1s-longer-lived toast does not intercept any bottom-control tap
• pnpm build — ok

**Third in a linear stack: #179 → #180 → this** (branched off #180). Until those merge, this PR's diff also shows their commits `c1805e5`/`fb7490f`; review the top commit `400b6ac` (only `Toast.svelte` + `app.svelte.ts`). No file overlap with #179/#180 — stacked only to keep the test contour coherent. **Merge #179 → #180 → this.** ## What The info toast began drifting up and fading the instant it finished appearing (the CSS keyframes jumped from the 12% appeared-stop straight to the 100% risen-and-faded stop), so a glanced message was already leaving. ## Change Insert a ~1s hold at rest before the rise-and-fade: - `Toast.svelte`: animation 2s → 3s, keyframe stops at **8%** (appeared, ~240ms) and **41%** (end of the ~1s hold); the rise-and-fade tail keeps its original pace. Reduced-motion variant gets the same appear/hold/fade timing (fade only, no travel). - `app.svelte.ts`: `showToast` dismissal timer 2000 → 3000ms, in lockstep with the animation. The error toast (4s dwell, Svelte fly/fade) is unchanged. Cosmetic animation-timing only — no logic branch and no non-brittle test layer for it (an e2e timing assertion would be flaky), so no test added; eyeball on the contour. ## Verification (local) - `pnpm check` — 0 / 0 - `pnpm test:unit` — 396 passed - `pnpm test:e2e` — **190 passed** (Chromium + WebKit) — confirms the 1s-longer-lived toast does not intercept any bottom-control tap - `pnpm build` — ok

developer added 3 commits 2026-07-05 12:10:57 +00:00

feat(ui): hide current-host sign-in row in profile ... c1805e5b7c

Inside a Telegram/VK Mini App the host provider is auto-linked. Once the
player also linked an email, `canUnlink` turned true and the "Unlink"
control appeared on the host platform's own row — letting them unlink the
very platform they are signed in through, which is meaningless.

Gate the Telegram row on `!insideTelegram()` and the VK row on
`!insideVK()`, reusing the runtime host detectors that already gate the
"link" buttons. Symmetric: inside TG only the TG row is hidden (the VK row
still shows, since VK is not the current host), and vice versa. The web and
native builds are unchanged (both detectors are false there); the backend
is untouched — this is a UI display gate, and `linkUnlink` still refuses to
remove the last identity.

Docs: FUNCTIONAL.md (+_ru mirror).

fix(ui): poll for out-of-band email confirmation ... fb7490f1df

An email link/code can be confirmed out of band: the recipient taps the
one-tap link in the email, which confirms in another browser/session. The
backend already publishes a `notify` `profile` re-fetch signal for this
(handlers_auth.go handleEmailConfirmLink), and the client re-fetches on it.

But the live stream is single-shot with no replay: a Mini App backgrounded
while the user is in their mail app tapping the link drops the stream and
misses the event (the gateway hub has no subscriber to deliver to), and the
reconnect on foreground does not re-sync — so the open code form stayed
until a manual reload. On Telegram Desktop the app is never backgrounded,
so the push works and there was no bug.

Add a client-side fallback: while an add-email confirmation is pending
(a code was sent, no email yet), poll `profile.get` on a 4s interval and on
foreground regain until the address lands; the effect stops as soon as the
email appears. The live push still updates instantly when foregrounded —
this only covers the backgrounded-miss gap.

Tests: a mock e2e attaches the email WITHOUT emitting a live event (new
window.__mock.clearEmail / confirmEmailOutOfBand seams), so it exercises the
poll, not the push, and asserts the code form collapses into the email row.
Docs: ARCHITECTURE.md §10 notes the single-shot gap + the poll fallback.

fix(ui): hold info toast ~1s before it rises and fades ... 400b6ac2a5

The info toast began drifting up and fading the instant it finished
appearing (the CSS keyframes went straight from the 12% appeared-stop to
the 100% risen-and-faded stop), so a glanced message was already leaving.

Insert a ~1s hold at full opacity/rest before the rise-and-fade: extend the
animation 2s → 3s with keyframe stops at 8% (appeared, ~240ms) and 41% (end
of the ~1s hold), keeping the original rise-and-fade pace for the tail. The
reduced-motion variant gets the same appear/hold/fade timing (fade only, no
travel). The showToast dismissal timer is bumped 2000 → 3000ms to stay in
lockstep with the animation (the error toast's 4s dwell is unchanged).

owner approved these changes 2026-07-05 12:16:59 +00:00

developer merged commit ac383880b7 into development 2026-07-05 12:24:08 +00:00

developer deleted branch feature/toast-hold-before-fade 2026-07-05 12:24:08 +00:00

developer referenced this pull request 2026-07-05 14:04:12 +00:00

Release v1.10.0: banner colours + urgent, and 3 UI fixes #183

Sign in to join this conversation.

Reviewers

No Reviewers

owner

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

owner (Ilia) developer

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: developer/scrabble-game#181