Restore right-edge alignment of buttons in the shared AlertModal#244
Open
Fried333 wants to merge 9 commits into
Open
Restore right-edge alignment of buttons in the shared AlertModal#244Fried333 wants to merge 9 commits into
Fried333 wants to merge 9 commits into
Conversation
Paper's Dialog.Actions wraps its children in a flex row with
justifyContent: 'flex-end', so a single OK button sits flush against the
right edge of the dialog. The shared AlertModal in src/components/Alert.js
wraps the buttons in a horizontal ScrollView (presumably to handle the
many-buttons case), which overrides that layout: a horizontal ScrollView
fills its parent's width and aligns its inner content to the start, so
every button ends up on the left of the dialog regardless of screen size
or button count. The misalignment is most noticeable on narrower phones
but is unconditional — every alert in the app is affected.
Add `contentContainerStyle={{ flexGrow: 1, justifyContent: 'flex-end' }}`
on the ScrollView so that when its content is narrower than its viewport
(the common case — one or two short buttons) the inner content area
stretches to the full ScrollView width and the buttons stay pinned to the
right edge, matching the default Paper Dialog.Actions behaviour. When
content does overflow (many buttons or very long labels) `flexGrow: 1`
becomes a no-op and the ScrollView still scrolls horizontally as intended.
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.
Summary
Paper's
Dialog.Actionslays its children out in a flex row withjustifyContent: 'flex-end', so a single OK button normally sits flush against the right edge of the dialog. The sharedAlertModalinsrc/components/Alert.jswraps its buttons in a horizontalScrollView(presumably to handle the many-buttons case), which overrides that layout: a horizontalScrollViewfills its parent's width and aligns its inner content to the start, so every button ends up on the left of the dialog regardless of screen size or button count.The misalignment is unconditional — every alert in the app is affected — but is most noticeable on narrower phones where the gap between the button and the right edge is wider in absolute pixels.
Fix
Add
contentContainerStyle={{ flexGrow: 1, justifyContent: 'flex-end' }}to theScrollView. When the inner content is narrower than the viewport (the common case — one or two short buttons), the content area now stretches to the fullScrollViewwidth and the buttons stay pinned to the right edge, matching the defaultDialog.Actionsbehaviour. When content does overflow (many buttons or very long labels),flexGrow: 1becomes a no-op and theScrollViewstill scrolls horizontally as intended.Diff
One file, four lines of diff:
Test plan
devand installed on an Android device. Every alert dialog (createAlert-driven) now renders its OK / action button on the right edge of the dialog as the design intended. Multi-button alerts still scroll horizontally when their combined label width exceeds the viewport.