diff options
| author | Richard Moe Gustavsen <richard.gustavsen@nokia.com> | 2011-02-18 09:19:58 (GMT) |
|---|---|---|
| committer | Richard Moe Gustavsen <richard.gustavsen@nokia.com> | 2011-02-18 09:29:23 (GMT) |
| commit | 5949c215bd53582d0c6481f606a9ec015f067b37 (patch) | |
| tree | e7f3046fc23e0649cbad626bd530813492993a92 /src/gui/painting/qgraphicssystem_p.h | |
| parent | e340844bd614add505a39a3a6b915632476f6305 (diff) | |
| download | Qt-5949c215bd53582d0c6481f606a9ec015f067b37.zip Qt-5949c215bd53582d0c6481f606a9ec015f067b37.tar.gz Qt-5949c215bd53582d0c6481f606a9ec015f067b37.tar.bz2 | |
Cocoa: fix crash when using a drawer with a focus widget
The crash happends when you close down an application that has a
drawer that contains a widget with keyboard focus. The NSView
backing this widget is then the first responder in Cocoa.
This bug was a bit more hard-boiled than usual, and I can't say I truly
understand whats going on. My findings are that both the drawer and the
parent window both points to the same view inside the drawer as its
first responder. And when deleting the drawer (togheter with the focus
widget), the parent window is left pointing to a first responder that
is actually deleted. Is seems that us refusing to release a view as first
responder if we have no attached widget is wrong. So we choose to return
YES instead, which after all makes much more sense.
Task-number: QTBUG-15897
Reviewed-by: msorvig
Diffstat (limited to 'src/gui/painting/qgraphicssystem_p.h')
0 files changed, 0 insertions, 0 deletions