Double clicking Workspace Switcher too fast switches workspaces and moves windows unpredictably

While on the TR or BR workspace, double clicking on the workspace switcher activates the TL workspace for me. Even if this might not be a supported input gesture it's still confusing.
I didn't see any window positions changed.

Maybe just use Super+S for now :)

there is another (older) bug about the same issue, which remember confirming but can't find right now.

A correct fix seems to wait for expo to finish animating before letting another click cancel it. Just like Super+S works...

This is bug-ish behavior within Expo itself. It can be reproduced without ever clicking the workspace launcher. You can click anywhere on the screen immediately after Super+s and Expo will switch straight back to the workspace nearest to the click, sometimes dragging windows along with it unpredictably.

A slight improvement that might be achievable is if the Workspace Launcher can "block" Expo from receiving clicks. But the bug still lies with Expo willing to process clicks during unpredictable animation.

I agree this bug should really be fixed in the Compiz Expo plugin. The proper fix would be for it to ignore mouse clicks until the Expo animation is finished. Moving to Compiz and will take a look soon.

This bug was fixed in the package compiz - 1:0.9.12.1+15.04.20150410.1-0ubuntu1

---------------
compiz (1:0.9.12.1+15.04.20150410.1-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.

  [ Chris Townsend ]
  * Expo plugin: Make sure the Expo animation is completed before
    allowing clicks to be handled. (LP: #1026553)
  * Grid plugin: Float to int division truncating caused a 1 px gap on
    the right side of right semi-maximized window when the workspace has
    an odd width. Fix is to add 0.5 to the float division first to
    account for any truncation error. (LP: #1294864)

  [ Eleni Maria Stea ]
  * Change in GLVector implementation
  * Minor change: when the skydome was working (in the c version of
    compiz) it was rendered on top of the background so, there was no
    need to clear the screen before drawing (the skydome was rendered on
    top of the garbage from previous renderings, hiding it). In the c++
    plugin, the skydome is buggy and the background is visible (as well
    as some garbage from previous renderings). A temporary
    glClear(GL_COLOR_BUFFER_BIT) was added until we fix the skydome and
    the other cube bugs.
  * glDisableOutputClipping was not implemented in 3d.cpp => a parent
    class glDisableOutputClipping was called, causing 2d clipping
    artifacts (the 3d cube was clipped and you couldn't see the windows
    move)

  [ Marco Trevisan (Treviño) ]
  * OpenGL: don't hardcode X11 sync blacklisted models, but use settings
    instead (LP: #1441190)

  [ Stephen M. Webb ]
  * (Ubuntu packaging) migrate migration scripts to Python3. (LP:
    #1440548)
  * exclude Wine applications from window close animations (LP: #957879)
 -- CI Train Bot <email address hidden> Fri, 10 Apr 2015 21:55:34 +0000

[ Chris Townsend ]
  * Expo plugin: Make sure the Expo animation is completed before
    allowing clicks to be handled. (LP: #1026553)

Sorry to be a bother, but this fix forces me to wait until the animation is finished before right clicking on my desired desktop, otherwise the plugin goes straight back to the workspace I came from.

Example:
* My desktop wall is 6 workspaces arranged as 3x2.
* I use the top right hot corner to activate Expo.
* Expo animation is set to the default 0.3 seconds.

When I use the top right hot corner, I move my mouse quickly to where I anticipate my desired workspace to be. I then right click on that as soon as I realise my mouse is above that, which is usually before the Expo animation finishes. I then get dropped back to the workspace I came from.

This happens more than 50% of the time (I've had 15.04 installed for less than 24 hours). I tried a workaround: setting the animation speed to 0.1 and 0.2 seconds, which is too fast for me and is visually jarring. 0.3 seconds is nice, but makes Expo uncomfortable to use.

Hey Lem,

No bother at all:)

I can reproduce your issue. When I did this fix, I only took into account double-click, ie, mouse button 1 and not any other potential mouse buttons. Basically, any other mouse buttons pressed just cancel the Expo.

The previous behavior of allowing mouse clicks to occur while Expo is animating in not correct, but you have developed a work-flow based on an incorrect behavior. That is fine, but now we have to figure out a solution that still fixes this bug but doesn't ruin your current way of doing things:) Could you open a new bug about this "regression"? We can discuss in there my ideas on how to fix this. Thanks!