Details
-
Bug
-
Resolution: Cannot Reproduce
-
P1: Critical
-
5.12.3
-
None
-
macOS 10.14.6 but probably not specific to this macOS version.
Description
Under some circumstances, QGuiApplication::focusWindow() returns a pointer to a window that has already been destroyed. I have a suspicion that the presence in my application of an NSWindow that wasn't created by Qt has something to do with it.
The problem didn't occur in Qt 5.9.2.
The steps to reproduce the issue in the full application :
- open an application modal window
- click the desktop (this will cause the Tools windows and the "foreign" NSWindow to be hidden but not the modal window)
- close the modal window by clicking the top left close button (application doesn't become active)
- click the application icon in the dock. This activates the application (bringing back the "foreign" NSWindow and the Tools windows) and triggers a syncing of the backing store which at some point in the call stack calls QGuiApplication::focusWindow() which crashes the application as the returned NSWindow * is no longer valid (it points to the modal window's window handle).
I've found a way around the problem by changing the focus_window static member of QGuiApplicationPrivate from
static QWindow * focus_window;
to
static QPointer< QWindow > focus_window;
and updating QGuiApplication::focusWindow() to the following:
QWindow *QGuiApplication::focusWindow()
{
return QGuiApplicationPrivate::focus_window ? QGuiApplicationPrivate::focus_window.data() : nullptr;
}
(and some additional changes needed for the type change). This of course alleviates the symptom but doesn't fix the actual problem that focus_window should have been reset to nullptr.
I haven't come round to creating a minimal application that reproduces the problem yet but wanted to log it already anyway because I've found a patch around the problem and am hoping that someone familiar with how focus_window is updated on macOS maybe sees what's going wrong.