You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Settings → Home, opening a recent meeting's ⋯ overflow menu and choosing Delete meeting does nothing: no confirmation dialog, no deletion. The other menu actions behave like this:
Show transcript in Finder / Show audio in Finder — work
Report issue — works (opens the feedback sheet)
Delete meeting — dead (no popup, no action)
Root cause
Two stacked defects on the Home recent-meeting row path:
Menu handler ran inside the menu modal loop.ClosureMenuItem.invoke() (in HomeView.swift) called its handler synchronously, while still inside NSMenu.popUp's modal event-tracking loop. SwiftUI will not present an .alert(item:) / .sheet(item:) from that nested loop, so the Delete handler set homeDeleteConfirmation but nothing showed. PR Fix Home dashboard row actions, hover reveal, and stats focus ring #1110 fixed the handler firing at all (it previously no-op'd on a deallocated weak target), which exposed this next layer.
Three legacy .alert(item:) were stacked on one view.homeDeleteConfirmation, homeDeleteFailure, and pendingAudioRetentionWindow each had their own .alert(item:) on the settings root (TranscriptedSettingsView.swift). SwiftUI keeps only the last stacked legacy alert, so the delete confirmation (first) and the delete-failure alert were both shadowed. Only the audio-retention alert (last) could present.
Report issue opens a .sheet, and stacked sheets do not shadow each other, so it only needed fix 1.
Repro
Settings → Home
⋯ on any recent meeting → Delete meeting
Expected: confirmation dialog. Actual: nothing.
Fix
Defer ClosureMenuItem's handler to the next main-runloop turn (off the menu loop), keeping the handler owned by the item so it cannot deallocate first.
Collapse the three stacked alerts into a single .alert(item: rootAlertBinding) that presents whichever state is set; call sites unchanged.
Reported on
mainafter rebasing onto upstream.What happens
In Settings → Home, opening a recent meeting's ⋯ overflow menu and choosing Delete meeting does nothing: no confirmation dialog, no deletion. The other menu actions behave like this:
Root cause
Two stacked defects on the Home recent-meeting row path:
Menu handler ran inside the menu modal loop.
ClosureMenuItem.invoke()(inHomeView.swift) called its handler synchronously, while still insideNSMenu.popUp's modal event-tracking loop. SwiftUI will not present an.alert(item:)/.sheet(item:)from that nested loop, so the Delete handler sethomeDeleteConfirmationbut nothing showed. PR Fix Home dashboard row actions, hover reveal, and stats focus ring #1110 fixed the handler firing at all (it previously no-op'd on a deallocated weak target), which exposed this next layer.Three legacy
.alert(item:)were stacked on one view.homeDeleteConfirmation,homeDeleteFailure, andpendingAudioRetentionWindoweach had their own.alert(item:)on the settings root (TranscriptedSettingsView.swift). SwiftUI keeps only the last stacked legacy alert, so the delete confirmation (first) and the delete-failure alert were both shadowed. Only the audio-retention alert (last) could present.Report issue opens a
.sheet, and stacked sheets do not shadow each other, so it only needed fix 1.Repro
Fix
ClosureMenuItem's handler to the next main-runloop turn (off the menu loop), keeping the handler owned by the item so it cannot deallocate first..alert(item: rootAlertBinding)that presents whichever state is set; call sites unchanged.Fix + source-contract coverage in the linked PR.