summaryrefslogtreecommitdiff
path: root/render
diff options
context:
space:
mode:
authorCarlos Garnacho <carlosg@gnome.org>2012-12-19 18:42:39 +0100
committerPeter Hutterer <peter.hutterer@who-t.net>2013-01-09 11:23:12 +1000
commitdf746a73410b892a4d41a2934cf9cd2e8ad7ba51 (patch)
tree1acb605d4c9b4ef88646157e3702f3766054b141 /render
parent0fbd779a82919d5dbf8776be9b57a76c0eae6b14 (diff)
render: Unwrap early on the animated cursor BlockHandler
The loop above the previous call may end up triggering other handlers attaching to the same function slot, so unwrapping the handler after that could leave the just attached handler in a dangling but not unset state. This issue was most visible on the XO, where destroying a window with an animated cursor set and running would trigger this inconsistent state, never calling the miSpriteBlockHandler again after the animated cursor is unset. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Diffstat (limited to 'render')
-rw-r--r--render/animcur.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/render/animcur.c b/render/animcur.c
index ebc5b8ef7..9cbba83fa 100644
--- a/render/animcur.c
+++ b/render/animcur.c
@@ -143,6 +143,8 @@ AnimCurScreenBlockHandler(ScreenPtr pScreen,
Bool activeDevice = FALSE;
CARD32 now = 0, soonest = ~0; /* earliest time to wakeup again */
+ Unwrap(as, pScreen, BlockHandler);
+
for (dev = inputInfo.devices; dev; dev = dev->next) {
if (IsPointerDevice(dev) && pScreen == dev->spriteInfo->anim.pScreen) {
if (!activeDevice) {
@@ -180,7 +182,6 @@ AnimCurScreenBlockHandler(ScreenPtr pScreen,
if (activeDevice)
AdjustWaitForDelay(pTimeout, soonest - now);
- Unwrap(as, pScreen, BlockHandler);
(*pScreen->BlockHandler) (pScreen, pTimeout, pReadmask);
if (activeDevice)
Wrap(as, pScreen, BlockHandler, AnimCurScreenBlockHandler);