diff options
author | Jan Arve Sæther <jan-arve.saether@qt.io> | 2018-09-10 16:30:26 +0200 |
---|---|---|
committer | Jani Heikkinen <jani.heikkinen@qt.io> | 2018-09-11 11:45:18 +0000 |
commit | 0431e462dff57bc6a9010649c0d7f153d91cab2d (patch) | |
tree | 435ad3a647040f0f568d19dd58ad43b8c465ce6d /src/quick/qtquickglobal_p.h | |
parent | 72cc53b5ee8bd6821d0094ad0c5c45d7a269f943 (diff) |
Add some null pointer checks to avoid some rare crashesv5.11.2
The crashes happened because somebody was calling processEvents() from
a mouse/touch event handler that was running for a long time.
If we called processEvents() from the onPressed handler, and we released
the mouse while still not having returned from the onPressed handler, it
meant that we were actually delivering the release event before the
press event was fully delivered...
This should normally not be a problem, but QQuickWindow is reusing the
QQuickPointerEvent object for each incoming QEvent, which meant that
when we were delivering the release event, it would reuse (and overwrite)
the QQuickPointerEvent that the press event handler is still using....
This then caused some assumptions that the code made to be wrong.
This only avoids the crashes, and doesn't really fix the "out-of-order"
delivery and the state inconsistency that this can lead to (e.g. mouse
button states might be still wrong).
But on the other hand, it is not the recommended way of making a
long-running handler not block the application. The proper way is to
create a thread that will run in the background, so that there would be
no need to call processEvents() in the event handler.
Change-Id: I6fa5d4f5748ef30d082a210f03ef382922bd4b29
Task-number: QTBUG-65454
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Diffstat (limited to 'src/quick/qtquickglobal_p.h')
0 files changed, 0 insertions, 0 deletions