Fix hero rail hit-testing: constrain tap area to laid-out frame - #94
Merged
Conversation
BackdropLogoOverlay's backdrop image is `.resizable() .aspectRatio(contentMode: .fill)`, which lays out larger than its container whenever the source image's aspect ratio doesn't match — `.clipped()` only crops what's rendered, not the view's actual layout geometry. With no explicit tap shape, HeroRailCard's NavigationLink inferred its hit-test region from that oversized, unclipped geometry instead of the visually clipped frame. Confirmed live via an accessibility-tree dump on the hero rail: every loaded page's reported frame was ~758pt wide against a 402pt screen/page width (one page still on its loading placeholder measured correctly at 402pt in the same dump, isolating the backdrop image). The overlapping regions between adjacent pages resolved to whichever page was later in hit-test order — the *next* page — matching the reported "right side taps the next item" bug. Adds `.contentShape(Rectangle())` to BackdropLogoOverlay itself so any caller wrapping it in a tappable control gets a correctly-bounded tap area, not just the hero rail. Re-verified post-fix: every hero page now reports exactly `width: 402` with no overlap, and a live tap near the right edge of the current item opens that item's own detail page. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Bug
The Home screen hero item was very hard to tap: taps on the center mostly did nothing, and taps on the right side of the currently-visible item registered as a tap on the next item instead.
Root cause
BackdropLogoOverlay's backdrop image is.resizable().aspectRatio(contentMode: .fill), which lays out larger than its container whenever the source image's aspect ratio doesn't match the frame —.clipped()only crops what's rendered, not the view's actual layout geometry. With no explicit tap shape,HeroRailCard'sNavigationLinkinferred its hit-test region from that oversized, unclipped geometry instead of the visually clipped frame.Confirmed live via an accessibility-tree dump on the hero rail: every loaded page's reported frame was ~758pt wide against a 402pt screen/page width (one page still on its loading placeholder measured correctly at 402pt in the same dump, isolating the backdrop image as the cause). The overlapping regions between adjacent pages resolved to whichever page was later in hit-test order — the next page — matching the reported asymmetry.
Fix
Adds
.contentShape(Rectangle())toBackdropLogoOverlayitself, so any caller wrapping it in a tappable control gets a correctly-bounded tap area — not just the hero rail.Verification
width: 402, matching the true page width, no overlap.BackdropLogoOverlayTests(7 tests, tilt-rotation math, unaffected by this change) still pass.🤖 Generated with Claude Code