Replace iPad-broken confirmation dialogs with menus and alerts - #224
Merged
Merged
Conversation
On iPad a confirmationDialog is presented as a popover, and on iPadOS 26 — with the UIDesignRequiresCompatibility opt-out this app ships — that popover renders as an empty panel with no readable content. Verified by A/B on an iPad (A16) / iPadOS 26.1 simulator: with the key present the dialog shows nothing; remove the key and the same dialog renders. The song-title long press now opens a context menu instead. That is the native match for a long press, draws its own chrome, and anchors to the title rather than floating over the tab bar. It also says why the refresh is unavailable when the song is already queued, where the old gesture was silently a no-op. The five remaining dialogs are all tap-triggered confirmations carrying a message, so they become alerts, which present as a centred modal on iPad and are unaffected by the opt-out. Two get `presenting:` so their message can no longer render empty, and the MusicBrainz search dialog gains a real two-way isPresented binding in place of a `.constant`. Alerts only take buttons, so its "View on MusicBrainz" link opens through the environment. Alert buttons inherit the tab bar's brand tint, which was navy on near-black whenever the device was in dark mode. ApproachNoteTheme is a single hardcoded light palette, so the app's own screens are light either way and only the system surfaces we don't draw were drifting. Declaring the app light-only keeps them in step, as the Mac app already does with .preferredColorScheme(.light). Each of the six was driven to on screen on the iPad simulator. Co-Authored-By: Claude Opus 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.
Long-pressing a song title on iPad opened a menu with nothing readable in it — visible in the original report as a pale rounded panel over the tab bar with a downward arrow and no content.
Cause
On iPad a SwiftUI
confirmationDialogis presented as a popover, and on iPadOS 26 — with theUIDesignRequiresCompatibilityopt-out this app ships — that popover renders empty. Verified by A/B on an iPad (A16) / iPadOS 26.1 simulator: with the key present the dialog shows nothing at all; remove the key and the same dialog renders normally. The key stays (the app depends on it for opaque bars), so the dialogs go instead.Changes
Song refresh (
SongDetailView) — now a.contextMenuon the title. Native match for a long press, draws its own chrome, anchors to the title instead of floating over the tab bar. It also explains why refresh is unavailable when the song is already queued; the old gesture was silently a no-op in that state.The other five are all tap-triggered confirmations carrying a message, so they become alerts — centred modals on iPad, unaffected by the opt-out:
MusicBrainzSearchSheet"Request Song"isPresentedbinding replacing a.constant;Link→ Button via@Environment(\.openURL), since alerts only take buttonsYouTubeImportView"Link to Recording?"AuthorityRecommendationView"Delete Authority Reference"presenting:so the message can't render emptyAuthorityRecommendationView"Link to This Recording"RecordingContributionEditView"Delete Contribution"UIUserInterfaceStyle = Light— alert buttons inherit the tab bar's brand tint, which was navy on near-black whenever the device was in dark mode. This was pre-existing and hit the old dialogs equally.ApproachNoteThemeis a single hardcoded light palette, so the app's own screens render light either way and only the system surfaces we don't draw were drifting out of step. The Mac app already does this with.preferredColorScheme(.light).Verification
Each of the six was driven to on screen on the iPad (A16) / iPadOS 26.1 simulator and read, not just compiled. The five alert sites are all behind login, so the auth gates were temporarily bypassed and the YouTube share payload stubbed to reach them; all of that scaffolding is reverted and both the
ApproachNoteandApproachNoteMacschemes build clean. Each alert was dismissed without confirming, so nothing was written to production.Not fixed here
Result rows in the MusicBrainz sheet only respond to taps landing on the text —
.buttonStyle(.plain)hit-tests the label's content shape, so the empty part of the row is dead. Pre-existing and unrelated; a.contentShape(Rectangle())on the row label would fix it.🤖 Generated with Claude Code