0ed4dc554c
The implementation of QCocoaWindow::setVisible is not idempotent, as for modal windows it calls beginSheet/endSheet or starts/ends modal sessions, which will confuse the AppKit modal session stack. Once a window has been shown QWindowPrivate::setVisible hides/masks this issue, by returning early if the visibility has not changed, but during first show QWindowPrivate::setVisible will update the QWindow state, before creating the platform window. If the platform window then picks up the QWindow's visible state during creation, it will result in one QPlatformWindow::setVisible() call during creation, and another one via QWindowPrivate::setVisible after the platform window has been created. To fix this we can check the existing NSView.hidden state and skip the setVisible call if it's already up to date. But one complication is that our QCocoaWindow::setVisible has different behaviors depending on whether the window has been initialized yet or not, due to how handleGeometryChange skips sending geometry changes for uninitialized windows. So we need to also bail out if we're still initializing the window. This is fine, as we know we'll get a follow up setVisible call via QWindow, both when QWindow itself creates the platform window as part of setVisible, as well as when the user does a two step create and then show. For good measure we throw in a recursion check as well, in case some of the logic in QCocoaWindow::setVisible before we update NSView.hidden recurses back into QCocoaWindow::setVisible. Pick-to: 6.5 Change-Id: Ibdcf4859e58d6684aac4490126d35eb12fdd5943 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> (cherry picked from commit be268ae19731ab854931e43eea83e0e140ec2538) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>