aboutsummaryrefslogtreecommitdiffstats
path: root/LICENSE.GPL2
diff options
context:
space:
mode:
authorJan Arve Sæther <jan-arve.saether@qt.io>2018-09-10 16:30:26 +0200
committerJani Heikkinen <jani.heikkinen@qt.io>2018-09-11 11:45:18 +0000
commit0431e462dff57bc6a9010649c0d7f153d91cab2d (patch)
tree435ad3a647040f0f568d19dd58ad43b8c465ce6d /LICENSE.GPL2
parent72cc53b5ee8bd6821d0094ad0c5c45d7a269f943 (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 'LICENSE.GPL2')
0 files changed, 0 insertions, 0 deletions