I'm on macOS 26.4 (SwiftUI + SwiftData + AppKit bridging). I have a SwiftUI canvas where each child view (a card) carries a per-card AppKit context menu via an NSViewRepresentable overlay (a small NSView subclass that overrides menu(for:) and returns an NSMenu whose items invoke a Swift closure).
The closure for the "Delete" item removes the underlying model object. SwiftData mutates → SwiftUI re-emits the canvas → the card containing the menu's anchor NSView unmounts → that anchor NSView is removed from the AppKit view hierarchy.
After this happens, the entire window's SwiftUI gestures stop receiving mouse events: pan, zoom, taps on a separate background Color view all go silent. The window's first responder ends up at the NSWindow itself. The wedge persists across switching to a sibling SwiftUI view in the same window (different SwiftData root), so the bad state is at the window/event-routing level, not in any one SwiftUI subtree.
The wedge is reliably cleared by another right-click that successfully shows + dismisses any menu — strongly suggesting AppKit's menu/event-tracking cleanup is left in a half-finished state because the anchor view went away during the cleanup window.
I've already verified:
- Switching from explicit NSMenu.popUpContextMenu(_:with:for:) to overriding menu(for:) does not change the behavior.
- Deferring the model deletion via DispatchQueue.main.async, asyncAfter (30 ms), or RunLoop.main.perform(inModes: [.default]) either doesn't help or only avoids the wedge if the delay is
long enough to be perceptible (seconds), implying the cleanup window is event-driven, not time-driven.
- Triggering the same deletion from a SwiftUI Button (no AppKit menu involved) never wedges.
My current understanding is that the standard AppKit pattern (e.g., NSTableView, NSOutlineView) attaches the context menu to a stable parent view, never to the per-row view itself, precisely so the menu's anchor outlives any single row's deletion. Restructuring my code so a single canvas-level AppKitContextMenuRegion returns the appropriate menu via hit-testing in menu(for:) should avoid the issue, but I'd like to confirm:
- Is the assumption that an NSMenu's anchor view must outlive the menu's tracking-end cleanup documented anywhere, or is it implicit?
- Is there a supported way to safely use a per-row anchor view that gets deleted by the menu's own action, or is the canvas-level / parent-level menu attachment the only correct
pattern? 3. Are there any post-tracking notifications or APIs that guarantee AppKit's cleanup is complete before the anchor view is allowed to be torn down (so a per-row anchor could be made safe with the right ordering)?
Thanks!