FIX: macOS popups dismissed by external AXRaise, swallowing the click

[crash0verride11]

Summary

On macOS, dropdowns and popups can stop registering clicks entirely. The popup opens, but clicking causes the dropdown or popup to dismiss without selection, and a in some cases a blank grey rectangle is left on screen floating above every
application — including when Bambu Studio is not frontmost. Keyboard navigation still works, so some selections become only reachable via the keyboard and some not at all.

My case that led to this patch the trigger was a mouse utility whose click-through feature raises the window under the cursor on mouse-down, so the raise arrived on every click. However, any accessibility client that raises windows can cause it — window managers, automation tools, assistive software. Difficult to disposes because the symptom looks like a Bambu Studio or wxWidgets bug, though it is an app conflict, and reproduces on no clean machine.

Diagnosis and fix

Any process holding macOS accessibility permission can raise another application's windows via the AXRaise action. While a popup is open this makes the raised window key, the popup resigns key, and wxPopupFocusHandler dismisses it:

AXRaise (another process, over Mach IPC)
-> -[NSWindow makeKeyAndOrderFront:]
-> -[NSWindow makeKeyWindow]
-> -[NSWindow resignKeyWindow]
-> wxWidgetCocoaImpl::DoNotifyFocusEvent
-> wxPopupFocusHandler::OnKillFocus

When the raise arrives on mouse-down the popup is gone before the click is delivered, so the click is lost. The popup's NSWindow is also left on screen at NSPopUpMenuWindowLevel, and since DropDown sets wxBG_STYLE_PAINT its background is never auto-erased, so it renders as a blank rectangle above every other application.

Everything deriving from PopupWindow is affected: DropDown, AmsMapingPopup, ColorPickerPopup. Dropdowns with submenus that are clicked sequentially appear to work because with two popups open the click dismisses one and still reaches the other.

wxWidgets is correct to dismiss a transient popup that lost focus; the problem is that the focus loss was not caused by the user. Push a guard ahead of wxPopupFocusHandler that swallows wxEVT_KILL_FOCUS while the pointer is still inside the popup, and lets it through otherwise.

Two key details:

• The guard must be installed on m_focus, not on the focus argument. On macOS wxPopupTransientWindow::Popup() reassigns m_focus = FindFocus() before pushing its own handler, and the two are different windows.
• wxFocusEvent::GetWindow() cannot be used to detect this: it is null for a key-window change, which is not a first-responder change. Hence the pointer-location test.

Clicking outside (wxPopupWindowHandler, EVT_LEFT_DOWN on m_child) and leaving the application are handled elsewhere and still dismiss normally.

macOS-only; no behaviour change on Windows or Linux.

Testing

macOS 26.5.2, Apple Silicon:

• Process preset dropdown — selects correctly
• Print-plate filament color picker — selects correctly
• Filament dropdown with submenus — selects correctly
• Click outside an open popup — still dismisses
• Cmd-Tab away with a popup open — still dismisses
• No stranded popup windows (measured via CGWindowListCopyWindowInfo: 0 onscreen
  windows at popup level, against 3 before the change)

Verified by instrumenting PopupWindow and reading the actual event order and the
backtrace at the point of dismissal.

Related issues

Likely fixes #7443 — The recording added to the issue mirrors some of the issues covered here. "Print preset selection dropdown in the Prepare tab is non-functional" and "Filament color selection dropdown in the Device tab cannot be changed" are two cases reproduced and fixed here.

Possibly related: #10140 (filament colour dropdown fails to apply, intermittent), if the jumps are the window being dismissed this sounds like the issue reproduced here.