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

Bug #277195 reported by Ian Redfern on 2008-10-02
This bug affects 9 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
compiz (Ubuntu)

Bug Description

Binary package hint: compiz

Intrepid i386, latest updates, Visual Effects set to Normal or Extra but not None.

I know that the mouse scrollwheel moves between desktops when used on the desktop background - as in Bug #175986.

However it also does this when over parts of application windows. Specifically, in Evolution, when the scrollwheel is used on the bar that lies between the toolbar and the messages (the one with the folder name, search box etc.), and also on the status bar. This is confusing - I can be using the scrollwheel to scroll through a message, and if I happen to be slightly out of position, I end up on another desktop - even if Evolution is maximised. When the mouse is over the menu or the toolbar, the scrollwheel correctly has no effect.

I thought this was an Evolution bug, and then I discovered Nautilus does it as well - but only when the mouse is over its status bar at the bottom of the window; Wireshark behaves similarly. I was expecting the scrollwheel to move between desktops only when the mouse was over the desktop.

description: updated
Christian González (droetker) wrote :

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.

Changed in compiz:
status: New → Confirmed
Aiden83 (aidendeem) wrote :

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

Kai Jauch (kaijauch) wrote :

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

  Installed: 1:0.8.2-0ubuntu8
  Candidate: 1:0.8.2-0ubuntu8
  Version table:
 *** 1:0.8.2-0ubuntu8 0
        500 jaunty/main Packages
        100 /var/lib/dpkg/status

Lightbreeze (nedhoy-gmail) wrote :

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.

Christian González (droetker) wrote :

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...)

positivek (anonyhole) wrote :

Please see my comment on bug 103306 here:

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.

Roshan George (roshan-george) wrote :

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.

Lightbreeze (nedhoy-gmail) wrote :

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.

Changed in hundredpapercuts:
status: New → Invalid

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.

Lightbreeze (nedhoy-gmail) wrote :

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.

Noé LECOCQ (noelecocq) wrote :

@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)

Lightbreeze (nedhoy-gmail) wrote :

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.

Christian González (droetker) wrote :

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.

Lightbreeze (nedhoy-gmail) wrote :

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?

Christian González (droetker) wrote :

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.

Changed in compiz (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Travis Watkins (amaranth) wrote :

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.

Changed in compiz (Ubuntu):
status: Triaged → Invalid
positivek (anonyhole) wrote :

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.

Christian González (droetker) wrote :

@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.

Travis Watkins (amaranth) wrote :

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.

Changed in compiz (Ubuntu):
status: Invalid → Confirmed

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

Changed in compiz (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers