Comment 22 for bug 1081843

Teo (teo1978) wrote :

Oh my god, point (1) was by design!

"""If the application *is not* in focus when the user moves their pointer over the Launcher app icon, the first mouse wheel click towards or away from the user should focus the application, and bring the top most window in the application's z stack to the front of the global z stack. Subsequent clicks of the mouse wheel the operate exactly as described above"""

For god's sake, this part needs to be reconsidered.

There is a basic principle in the way mouse wheel interaction has ALWAYS worked EVERYWHERE and you're breaking it here, and it's not a good innovation.
The mousewheel is used to move "something" forward and backward, and if you move it forwards and then backwards (or viceversa) of an equal amount, you go back to the original status.
Think about the way it is used for scrolling a page, or zooming in and out in an image editor, or (I hate it but unfortunately it's become widespread) switching between tabs in a browser, or between choices in a dropdown menu (even without unfolding it, regrettably, but again that's become popular). In all cases, the rule is never broken: if you move one step too much in one direction, either intentionally or accidentally (the latter being very common) you can always go back by moving the wheel one step in the following direction.

Now even if point 2 gets fixed , which is clearly a bug and contraddicts the "requirements" stated in this request (see #1263786), you are still breaking the "reversibility" of mouse wheel movements.