crueber commented

Owner

Clicking inside a thread card should highlight it like a pill jump does

What's requested

Clicking anywhere inside an inline thread card (ThreadCard) or staged card (StagedCard) should apply the same flash highlight that a Comments-index pill jump applies — the emerald ring — so the card the user is directly interacting with reads as the target, not just the card reached via the index. Today the highlight exists ONLY on the pill-jump path; a user who scrolls to or clicks into a card gets no equivalent feedback.

Evidence

The flash path exists only via the index: web/src/pages/Pull.jsx:1033-1041 (jumpToThread / jumpToStaged set flashTid / flashStaged), consumed at Pull.jsx:754 (ThreadCard) and Pull.jsx:693 (StagedCard).
The cards themselves carry no click handler; clicking inside one does nothing visual (comments, reply form, resolve/collapse links all render without any target highlight).

Fix shape

Any click inside a ThreadCard / StagedCard triggers the same flash state the pill jump sets (same emerald ring, same shared geometry), e.g. an on-click on the card root that sets the page-level flash for that tid/index.
Interaction with the collapse-unhighlight ticket: clicking "collapse" clears the flash (that ticket's fix), so a collapse click both flashes-and-clears in one gesture — land the flash lifecycle once, shared by both paths.
Decision points (implementer's call, note them):
1. Trigger scope: any click in the card vs. clicks on the card's controls only (ignore pure text-selection drags).
2. Whether clicking one card clears the flash from a previously flashed card (single-flash model, matching the pill jump's overwrite semantics).
3. Whether StagedCard joins (recommended: yes — same idiom, same slot).

Architecture notes

Client-only state change in Pull.jsx; no anchor/drift-hash surface touched (anchorContextSha inputs and the pinned vectors stay byte-identical).
Reuse the existing flashTid/flashStaged signals — do not introduce a second highlight mechanism.

Acceptance criteria

Clicking inside a thread card flashes it with the same ring a pill jump produces.
The pill-jump flash behavior is unchanged (still sets the same state).
A collapse click on a flashed card ends with the card collapsed and unhighlighted (consistent with the collapse-unhighlight ticket).
Clicks used for text selection inside markdown comment bodies do not produce a jarring re-flash (pick and document a threshold or scope).
Both themes verified.

# Clicking inside a thread card should highlight it like a pill jump does ## What's requested Clicking anywhere inside an inline thread card (ThreadCard) or staged card (StagedCard) should apply the same flash highlight that a Comments-index pill jump applies — the emerald ring — so the card the user is directly interacting with reads as the target, not just the card reached via the index. Today the highlight exists ONLY on the pill-jump path; a user who scrolls to or clicks into a card gets no equivalent feedback. ## Evidence - The flash path exists only via the index: `web/src/pages/Pull.jsx:1033-1041` (jumpToThread / jumpToStaged set `flashTid` / `flashStaged`), consumed at `Pull.jsx:754` (ThreadCard) and `Pull.jsx:693` (StagedCard). - The cards themselves carry no click handler; clicking inside one does nothing visual (comments, reply form, resolve/collapse links all render without any target highlight). ## Fix shape - Any click inside a ThreadCard / StagedCard triggers the same flash state the pill jump sets (same emerald ring, same shared geometry), e.g. an on-click on the card root that sets the page-level flash for that tid/index. - Interaction with the collapse-unhighlight ticket: clicking "collapse" clears the flash (that ticket's fix), so a collapse click both flashes-and-clears in one gesture — land the flash lifecycle once, shared by both paths. - Decision points (implementer's call, note them): 1. Trigger scope: any click in the card vs. clicks on the card's controls only (ignore pure text-selection drags). 2. Whether clicking one card clears the flash from a previously flashed card (single-flash model, matching the pill jump's overwrite semantics). 3. Whether StagedCard joins (recommended: yes — same idiom, same slot). ## Architecture notes - Client-only state change in `Pull.jsx`; no anchor/drift-hash surface touched (`anchorContextSha` inputs and the pinned vectors stay byte-identical). - Reuse the existing `flashTid`/`flashStaged` signals — do not introduce a second highlight mechanism. ## Acceptance criteria - [ ] Clicking inside a thread card flashes it with the same ring a pill jump produces. - [ ] The pill-jump flash behavior is unchanged (still sets the same state). - [ ] A collapse click on a flashed card ends with the card collapsed and unhighlighted (consistent with the collapse-unhighlight ticket). - [ ] Clicks used for text selection inside markdown comment bodies do not produce a jarring re-flash (pick and document a threshold or scope). - [ ] Both themes verified.

crueber added the

bug

enhancement

pull requests

labels

2026-09-15 14:03:08 +00:00

crueber added this to the v1 milestone

2026-09-15 14:03:08 +00:00

crueber referenced this issue

2026-09-15 14:03:22 +00:00

Collapsing a jumped-to thread card leaves it highlighted and refuses to collapse #573

crueber commented

2026-09-15 14:03:22 +00:00

Author

Owner

Shares the flash lifecycle with #573 — reuse the same set/clear mechanics; a collapse click flashes-and-clears in one gesture.

crueber added the

issues

label

2026-09-15 14:03:49 +00:00

crueber referenced this issue from a commit

2026-09-15 14:45:13 +00:00

FIXED (Forgejo #573) — collapsing a jumped-to thread card clears its flash

crueber referenced this issue

2026-09-15 14:45:18 +00:00

Fix #573: collapsing a jumped-to thread card clears its flash #577

crueber referenced this issue

2026-09-15 14:46:59 +00:00

Fix #573: collapsing a jumped-to thread card clears its flash #577

crueber referenced this issue

2026-09-15 14:47:17 +00:00

Collapsing a jumped-to thread card leaves it highlighted and refuses to collapse #573

crueber referenced this issue from a commit

2026-09-15 15:02:28 +00:00

FIXED (Forgejo #575) — clicking inside a thread/staged card flashes it like a pill jump

crueber referenced this issue from a pull request that will close it,

2026-09-15 15:02:30 +00:00

Fix #575: clicking inside a thread/staged card flashes it like a pill jump #579

crueber referenced this issue

2026-09-15 15:04:15 +00:00

Fix #575: clicking inside a thread/staged card flashes it like a pill jump #579

crueber closed this issue

2026-09-15 15:04:28 +00:00

crueber commented

2026-09-15 15:04:29 +00:00

Author

Owner

Fixed by #579 (merged): card-root click sets the same flashTid/flashStaged state as a pill jump (no scroll, single-flash overwrite, StagedCard parity); control clicks + selection drags ignored; collapse-click ends collapsed + unhighlighted via the #573 clear path (stopPropagation + control-ignore, no ordering hole). Verified: 1429 unit tests green (smoke excluded, pre-existing), vite/esbuild green, independent review APPROVE.

crueber referenced this issue from a commit

2026-09-15 15:04:29 +00:00

Merge pull request 'Fix #575: clicking inside a thread/staged card flashes it like a pill jump' (#579) from fix/issue-575 into main

crueber referenced this issue

2026-09-15 15:41:28 +00:00

Thread card collapse/expand label goes stale when the card is flash-expanded (click or jump) #580

crueber referenced this issue

2026-09-15 16:27:30 +00:00

Fix #580: thread card collapse/expand label derives from open() #582