Repository navigation
[Bug] Item, ListItem: a link row follows its link only from the label column, though the whole row looks clickable #9537
Description
Description
A ListItem (or Item) with href shows the whole row as clickable: the root takes the pointer cursor and the hover layer (isInteractive && styles.interactive, Item.tsx#L917). But only the label column is the link. The invisible anchor wraps the label and description alone (#L797, invisibleAnchor, #L446), with no overlay stretched over the row. The root's click handler only calls onClick (#L762), which a link row doesn't have.
So a click on the row's padding, on its startContent (an avatar) or on its endContent (a date) does nothing, though the cursor says it is a link. An onClick row behaves differently: its root handler runs onClick for a click anywhere on the row. With align="first-line" the anchor is only as tall as its lines. In a two-line row on a phone it measured 39.2 px inside a 63.7 px row, so most of the row's touch area misses the link.
Expected: a click or tap anywhere on a link row that doesn't land on a nested control follows the link, as it runs onClick on a button row. One way is to stretch the anchor over the row with a positioned ::after, keeping a slot that holds a control above it.
Reproduction
import {List, ListItem} from '@astryxdesign/core';
export function Repro() {
return (
<List>
<ListItem
href="/candidates/1"
label="Đặng Thu Hà"
description="Chưa ứng tuyển"
startContent={<span>ĐH</span>}
endContent={<span>Hôm qua</span>}
align="first-line"
/>
</List>
);
}- Hover the row: the whole row shows the pointer cursor and the hover layer.
- Click "Đặng Thu Hà": the link opens.
- Click "ĐH", "Hôm qua" or the row's padding: nothing happens. In jsdom, a document click listener sees an
<a>in the event's path only for the click on the label.
Astryx Version
@astryxdesign/core@0.7.5, still present on main (9297ef4)
Environment
Any browser; reproduced in jsdom (Vitest, Testing Library) and measured in Chromium at 390 × 844. Affects pointer and touch users. Keyboard users are unaffected, since the anchor takes focus.
Activity
HelloOjasMutreja commentedon Nov 2, 2026
I read the current
Item.tsxand this reproduces: thehrefbecomes aRowAnchoraround the label and description only (invisibleAnchor), while the root takes the pointer cursor and hover layer fromisInteractive, and itshandleContainerClickonly forwards toonClick. A link row has none, so a click on the avatar, end content or padding is a no-op. Keyboard use is unaffected, as you note.This looks like a bug fix with no new API, but there are two ways to restore it and they differ in what the browser keeps natively, so I would like a maintainer's preference before anyone writes it:
hrefrow,handleContainerClickcalls the existinganchorRefanchor when the click did not land on a nestedbutton, a, input, select, textarea(the guard it already has). The click is re-dispatched with the original event's modifier keys, so Ctrl/Cmd/Shift-click still opens a new tab or window. No new CSS and no change to hit testing. The cost: right-click "open link in new tab", middle-click and the status-bar URL still only work over the label column.::after, keeping a slot that holds a control above it. Everything native then works across the whole row, including the context menu and middle-click. The cost: it changes hit testing forstartContentandendContent, so any non-control content there (text selection, a tooltip target, a custom handler) needs a stacking decision. I found no stretched-link precedent inItem,List,CardorTable, so this would set a new convention.I lean to option 1 as the smaller restoration, with the native-menu gap noted in the docs, unless you would rather have option 2's full native behaviour. Either way I would add tests for: a click on
startContent,endContentand the padding following the link, a click on a nested control not following it, a disabled row staying inert, and a modified click keeping its modifiers.One sequencing note: option 1 edits
handleContainerClick, which #9393 also changes (its foreign-target guard). I would build it on top of #9393 once that lands, or fold it in if you prefer.I will not start until one of the two is confirmed.