Plumb isSelectable into ApplyItemContentInfo#623
Open
RoyalPineapple wants to merge 2 commits into
Open
Conversation
Add an `isSelectable` property to `ApplyItemContentInfo`, populated from the item's `selectionStyle.isSelectable`. This lets content views know when an item is interactive (`.tappable`, `.selectable`, `.toggles`) so they can represent themselves accordingly, e.g. by applying the `.button` accessibility trait for VoiceOver. TBHFUZZ-165 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4b2dc6e to
c2f8aef
Compare
Drops the `= false` default on the new public `isSelectable` property so it matches the sibling `isReorderable` (no default) and makes any future internal construction site that omits it a compile-time error rather than a silent wrong default. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
robmaceachern
approved these changes
Jun 9, 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
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.
Why
A
ListableUIitem's selection behavior lives in its wrapper —Item.selectionStyledrives the tap handling, highlight, and selection state at the list level. The containedItemContentview that actually renders on screen has no way to know that its surrounding cell is interactive.That's a problem for accessibility: when a row is tappable, the content view often needs to represent that itself (for example by applying the
.buttonaccessibility trait so VoiceOver announces the row as actionable). Without this signal, the content view is blind to the interaction happening in its wrapper and can't reflect it.What
Adds an
isSelectableflag toApplyItemContentInfo, so a content view is told — atapply(to:for:with:)time — whether the item it lives in is interactive.It's populated in
PresentationState.ItemState.applyTofromselectionStyle.isSelectable:truefor.tappable,.selectable, and.togglesfalsefor.notSelectableLive selection/highlight state is already available via
info.state; this fills the remaining gap of "is this row interactive at all." No trait is forced at the ListableUI/Blueprint level — what to do with the signal stays each content view's call.TBHFUZZ-165
Checklist
Please do the following before merging:
Mainsection.This issue was discovered via agentic fuzz testing using The Button Heist.
🤖 Generated with Claude Code