Repository navigation
macOS: do not require the nonactivating style bit once an owned Cocoa popup is shown - #1
Merged
Conversation
… is shown Opening any Popup or ContextMenu on macOS threw "The owned Cocoa popup identity changed" from CocoaOwnedPopupSurface.Enter() and, in a host that does not catch it, ended the process. OwnedOperations.IsCurrent compared the panel's styleMask with NSWindowStyleMaskNonactivatingPanel. Traced step by step, the panel keeps that bit through creation, addChildWindow:ordered: and orderFront:, the show succeeds (host identity, visibility, parent and hidesOnDeactivate all hold), and the next IsCurrent reads styleMask == 0. Every other check in IsCurrent is true at that point. Nothing in ProGPU writes the panel's style after creation; the likely cause is AppKit reporting the bit as cleared once the panel is ordered in as a child, which was not confirmed. Reject only style bits the panel was never given instead of requiring the creation-time value exactly. The other identity checks (panel and view class, content view and window links, nil delegate, NSPanel kind, worksWhenModal, becomesKeyOnlyIfNeeded, not floating, not released when closed, cannot become key or main, owner lease) are unchanged. Checked in OpenDevelop on macOS 27.0.1 with this change in the host: a real right-click ContextMenu and a toolbar button that opens a ContextMenu pass three runs in a row with no "identity changed" and no FATAL, and the full 23-test Terminal pad suite passes (the Terminal add-in also had to stop drawing toolbar and find-bar buttons as characters, a separate issue). Reported upstream as wieslawsoltes#401.
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.
Fixes the macOS crash reported upstream as wieslawsoltes#401: opening any
Popup/ContextMenuthrowsThe owned Cocoa popup identity changedfromCocoaOwnedPopupSurface.Enter().Cause
OwnedOperations.IsCurrentrequiresstyleMask == NSWindowStyleMaskNonactivatingPanel. The panel keeps that bit throughcreation,
addChildWindow:ordered:andorderFront:, the show succeeds, and the nextIsCurrentreadsstyleMask == 0(all other checks true). The likely cause is AppKit reporting the bit as cleared once the panel is ordered in as a child; not confirmed.
Change
One line: reject only style bits the panel was never given (
(styleMask & ~NonactivatingPanelStyle) == 0) instead of requiringthe creation-time value exactly. Every other identity check is unchanged.
Verified (OpenDevelop, macOS 27.0.1, this change in the host)
ContextMenu: 3 runs in a row pass (one earlier run failed because the click was not delivered; the menu never opened and there was no exception). A toolbar button opening aContextMenu: passes once on its own and once inside the full suite. Noidentity changedand noFATALin any run.▲▼✕▾, a separate issue).Not verified
ComboBox,ToolTip), and CI.run first; the form in this PR is what the 3-run and 23-test results above used.
Not done here
Per
openavalon/AGENTS.md, a ProGPU change needs LibreWPF's and LibreWinForms' ProGPU submodules advanced to the same commit and thepackages republished. That is not part of this PR.