Mouse scroll wheel moves between desktops when over parts of application windows

I don't know if it's a compiz problem (since it just is reproducible with visual effects "normal" or "extra" - with "none" AFAIK compiz is not used as window manager, but metacity).

It affects all programs, and always the space between tree views e.g. or other GTK elements - this space between the widgets seems to be the base window background, and mouse wheel clicks seem to be able to "pass through" this surface, they are passed to the Desktop somehow.
I don't know neitehr GTK nor C, so I can't help more finding where the problem is.

I attached a screenshot of synaptic - and marked all the gaps with red - the "sliders" between the left and right side/ between the upper list and lower description are NOT affected, I marked them red falsely.

But you can test it yourself with any program you want.
The Status bar at the bottom of Nautilus is affected too.

NOT affected at all (if I am right) are XUL surfaces like Firefox and Thunderbird, and QT->GTK engine programs like e.g. skype and virtualbox.

My mouse wheel unexpectedly scrolled to new desktop when mouse pointer was hovering between 'help' and 'unlock' of the System->Administration->Services Settings window.

Still an issue in Ubuntu 9.04. Scrolling when the mouse cursor is between GTK widgets and compiz is active causes a workspace switch.

I don't know whether compiz really is to blame here as metacity (to my knowledge) doesn't support changing the workspace by scrolling while hovering over the desktop. If anyone knows a method to determine if compiz really is the cause of the problem and not just making the problem visible, please feel free to post a comment.

Steps to reproduce:
1. Start rhytmbox
2. Position mouse cursor in the small area between the track position slider and the text label above it
3. Scroll mouse wheel

Expected result:
- Nothing happens

Actual result:
- Compiz gets the scroll event and switches to another workspace, as if the mouse cursor was directly over the desktop

compiz:
  Installed: 1:0.8.2-0ubuntu8
  Candidate: 1:0.8.2-0ubuntu8
  Version table:
 *** 1:0.8.2-0ubuntu8 0
        500 http://de.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Confirmed on Jaunty.
This is a bug with Viewport Switcher plugin. Disabling that plugin will stop mouse scroll workspaces - on desktop or otherwise.

Reproduce by enabling Viewport Switcher and setting Move Prev and Move Next to
Mouse Button 4 and 5.
 Try mouse scroll above the search box, near or on the 'Filter' label in CCSM
 This is annoying; the expected action is to do nothing in this situation and
to scroll workspaces only if hovering over the Desktop.

This bug effects at least the Banshee movie canvas, the Typing Break lock screen, the status bars at the bottom of most applications, and often on padding between GTK widgets.

Eh, I don't know, but this can't be a viewport switcher plugin bug, can it?
the viewport plugin should recieve the 4/5 mouse button events from the *desktop*, and not from the GTK widget backgrounds - so IMO this is a bug in GTK+, not?
(I'm no GTK programmer, that's just my plain - and perhaps wrong - logic...)

Please see my comment on bug 103306 here: https://bugs.launchpad.net/compiz/+bug/103306/comments/60

Basically, it reproduces a case where this bug occurs for the top-pixel row above a maximized window. The top-pixel row of a maximized window will send mouse scroll events to the same destination as those in this bug.

This happens to me too, both in Evolution as described in the bug report and in liferea at the status bar, and just above the song progress bar in Rhythmbox. The last instance is particularly annoying because I sometimes scroll over the progress bar to move the audio forward and if I miss I find myself on the wrong workspace. Very annoying indeed.

Disabling the Viewport Switcher stops the problem, but using the Compiz default settings the Viewport Switcher is enabled. Perhaps it is best to have the default set to disabled.

This bug is system wide, but does not impact standard workflow and is more broken software than a usability and design bug. This is not something users never notice and learn to work with, instead it is an annoying-when-you-encounter-it bug.

hundredpapercuts is addressing bug #147230, which is the same thing.

An "annoying-when-you-encounter-it bug" can also be considered a paper cut if it's easy enough to fix.

This is a separate issue. The other report says that scrolling on Desktop changing workspaces is problematic and whether to enable that plugin by default, whereas this deals with some problem in GTK windows.

Well, they address the same user experience, so they are same bug in
hundredpapercuts. Workspace switching on scroll will be disabled by default.

@Lightbreeze: "(it) does not impact standard workflow and is more broken software than a usability and design bug"

Sorry to say that this bug does strongly impact my workflow and is typically an usability bug. When I try to scroll inside a window I get transported to another workspace, it happens to me quite often (e.g. in Rythmbox) and it's quite annoying.

But it would be nice to keep an area of the screen where scrolling the mouse allows you to move between workspaces (maybe the upper or lower bar of the desktop)

Well, you can mouse wheel through workspaces in the switcher applet in the panel if you're running metacity but that's broken in compiz.

I must admit that it often painfully disturbs my work because I scroll in a window and accidentally have moved the mouse over a "bad hot area" in one of these programs, switching desktops - not mentioning the recent situation when I watched my mum scrolling, and suddenly having vanished all her windows - she didn't know about that and was deeply confused ;-)

This is *definitely* a paper cut IMO.

bug #147230 has decided to disable scroll on desktop by default which will reduce the exposure of this bug. I'm not sure, but I think in general paper cuts are for bugs which are experienced on the default install. Would having this plugin disabled solve the problem for you?

For me, not at all.
First thing if that plugin is disabled by default, is enabling it, because I often use scroll wheel on Desktopto change Desktops. So this would be just more work (enabling it), and helping us all to forget a bug which is not solved.
Anyway, for the mayority who use Ubuntu the first time and don't know about the mouse wheel on the desktop, it would be better, because they can't be surprised by it.

I don't understand exactly why this bug can't be downtracked to get rid of it - but I am no C/Gtk devel.

There is actually no way to fix this. If the part of the window you are scrolling on does not handle the scroll event it falls through the desktop window and thus the vpswitch action triggers. These apps would have to be patched to catch this event or the way the X event system works would have to change.

Do you mean there is no way to fix this in Compiz? If this is a Gnome thing (GTK?), then it should be assigned as such.

Some thoughts:

I think that window widget/containers that act as pass-through for user input events as a default is not safe. Events, as far as I know, do not fall through windows when using the non-Compiz window management, and such behavior probably never has been used in any windowing system. That is, the "window" is the last container into which events drop; and they should be "opaque" "sinks" unless specifically designed/programmed otherwise.

Maybe the GUI toolkit(s) used by at least Evolution, Gedit, Nautilus, F-Spot are _actively_ passing the events through? Should the toolkits be added as packages in the bug?

One test would be: Make the non-Compiz desktop do something (print a mesg?) with scroll events and see if the same bug occurs without Compiz enabled.

@Travis Watkins: This can't be true. This behaviour does not occur on right-clicks e.g.. And as positivek stated - this does NOT occur in Metacity, so it is definitely a Window manager problem IMO - just because the clicks are not handled by a gtk widget hty certaily are not passed to the desktop behind - IF (and that's the only possibility IMO) not a bug.
So please reassign it to compiz, or give proof of your statement.

I don't think it's fixable based on how the current code works and no one much cares to work on this part of the code but I'll reopen for now.

This is an old bug for an unsupported version. It has long since been fixed.