Repository navigation
fix(react): bound ScrollArea content to the viewport width - #57
Merged
Merged
Conversation
Radix's ScrollArea Viewport wraps children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so a long, non-wrapping line escapes the viewport's `overflow-x: hidden` (horizontal scroll stays off unless a horizontal scrollbar is mounted) and gets clipped instead of wrapping or scrolling within. Force that wrapper back to a block so content is bounded by the viewport width and inner scrollers own their own horizontal overflow. Fixes the execution-history run-detail drawer, where a long code preview pushed the meta grid and code block off screen.
aryasaatvik
added a commit
that referenced
this pull request
Aug 18, 2026
## Problem The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. ## Root cause The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. ## Fix Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. ## Verification - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Aug 23, 2026
## Problem The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. ## Root cause The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. ## Fix Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. ## Verification - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Aug 27, 2026
## Problem The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. ## Root cause The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. ## Fix Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. ## Verification - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Aug 28, 2026
## Problem The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. ## Root cause The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. ## Fix Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. ## Verification - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Aug 29, 2026
The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Aug 31, 2026
The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Sep 13, 2026
The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
aryasaatvik
added a commit
that referenced
this pull request
Sep 18, 2026
The run-detail drawer overflowed horizontally: a long, non-wrapping code preview pushed the meta-card grid and the code/result blocks off-screen, and the overflow was clipped with no way to scroll to it. The shared `ScrollArea` (Radix `@radix-ui/react-scroll-area`) Viewport wraps its children in a `display: table; min-width: 100%` div. A CSS table grows to its widest child's max-content, so the long code line expanded that wrapper past the viewport. The viewport's `overflow-x` is `hidden` unless a horizontal scrollbar is mounted (this one is vertical-only), so the excess was clipped rather than scrolled. That wrapper width then propagated back down, stretching the meta grid and keeping the inner code block's own `overflow` from engaging. Override that Radix wrapper to `display: block` (`[&>div]:!block`) on the Viewport so content is bounded by the viewport width. The meta grid fits its two columns and inner scrollers (the code/result blocks) own their own horizontal overflow. Direct-child selector only, so it does not flatten the grid/flex layouts nested inside. `ScrollArea` has a single consumer in the repo (the run-detail drawer), so the blast radius is contained. - format / lint / typecheck / scoped tests pass (react + execution-history) - Confirmed against the live DOM: the viewport and meta grid resolve to the viewport width (no overflow), and the code block becomes a real internal horizontal scroller (`scrollWidth > clientWidth`) Not yet covered by an e2e scenario; a drawer-overflow scenario would be a reasonable follow-up.
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.
Problem
The run-detail drawer overflowed horizontally: a long, non-wrapping code
preview pushed the meta-card grid and the code/result blocks off-screen, and
the overflow was clipped with no way to scroll to it.
Root cause
The shared
ScrollArea(Radix@radix-ui/react-scroll-area) Viewport wrapsits children in a
display: table; min-width: 100%div. A CSS table grows toits widest child's max-content, so the long code line expanded that wrapper
past the viewport. The viewport's
overflow-xishiddenunless a horizontalscrollbar is mounted (this one is vertical-only), so the excess was clipped
rather than scrolled. That wrapper width then propagated back down, stretching
the meta grid and keeping the inner code block's own
overflowfrom engaging.Fix
Override that Radix wrapper to
display: block([&>div]:!block) on theViewport so content is bounded by the viewport width. The meta grid fits its
two columns and inner scrollers (the code/result blocks) own their own
horizontal overflow. Direct-child selector only, so it does not flatten the
grid/flex layouts nested inside.
ScrollAreahas a single consumer in the repo (the run-detail drawer), so theblast radius is contained.
Verification
viewport width (no overflow), and the code block becomes a real internal
horizontal scroller (
scrollWidth > clientWidth)Not yet covered by an e2e scenario; a drawer-overflow scenario would be a
reasonable follow-up.