Repository navigation
fix(ui): let a sidebar row's pin button catch the first press - #396
Merged
Merged
Conversation
The row's hover actions ignored the pointer until :hover applied. A press that arrived before hover styles did (a warped or just-arrived cursor, a window activation) hit the row on pointerdown and the pin on pointerup, so the click went to their common ancestor and neither pinned nor selected. The actions now always take hits; only the enlarged hit area waits for hover so it can't catch presses meant for a neighbouring row. Why: packages/ui/src/components/session-item/session-item-actions.tsx#const SESSION_ACTIONS | row actions must be hit-testable without :hover, or a first press splits across row and button and is lost Why: packages/ui/src/components/session-item/session-item-actions.tsx#const ACTION_BUTTON | the enlarged hit area only takes presses on the hovered row, since it spills into neighbouring rows
This was referenced Oct 15, 2026
iamnbutler
added a commit
that referenced
this pull request
Oct 15, 2026
* fix(ui): keep a channel row's facepile clear of its pin The row's facepile sat under the hover actions at the same spot, so pointing at an avatar hit the pin, which takes presses even before hover since #396, and the facepile faded out on hover. The facepile and actions now share one trailing cluster, facepile first, so neither moves on hover and the pin stays at the row's right edge. Fixes #407 Why: packages/ui/src/components/session-item/session-item.tsx#const TRAILING | the gap between facepile and actions must cover the pin's hit-area spill so a face never pins * lane: sync row-facepile memory
This was referenced Oct 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #394
The row's hover actions (
SESSION_ACTIONS) hadpointer-events-noneuntil:hoverapplied to the row. When a press arrives before hover styles do (a warped or just-arrived cursor, a window activation),pointerdownhits the row's select button underneath andpointeruphits the now-hit-testable pin, soclickfires on their common ancestor and neither pins nor selects. Reproduced in headless Chromium against a sourceace serve --loopbackhost by sending a CDP press/release at the pin with no prior mousemove: events werepointerdown:SPAN/alpha,pointerup:svg,click:DIV/alpha, and nothing was pinned. A second press at the same spot worked, matching "the first click did nothing".The actions now always take hits. The 40px enlarged hit area still waits for the row's hover, since it spills into neighbouring rows and would otherwise steal presses meant for the row above or below.
Verified with Playwright
page.mouse(hover then click) in headless Chromium and WebKit: pin and unpin both work and the click doesn't select the channel; a press with no prior hover now pins and unpins; a press at the bottom edge of one row hits that row's pin, not the next row's hit area; clicking a row body still selects it.Built in Ace
No — built with Claude Code outside Ace by an overnight issue watcher, because this Mac's Ace Canary is a participant in the running two-person study (#218); dogfooding gap tracked in #5.