compiz eats mouse clicks at the border of the screen

[eppy 1]

Binary package hint: compiz

If you have a maximized Firefox window, throwing your mouse to the right usually lets you scroll, due to Fitt's law. However, with compiz or beryl enabled, it breaks Fitt's law because for some reason it reserves a pixel of space on the full right and left edges of the screen (not just the corner four hot spots that it uses for Expose-like stuff).

Also, if you have your panel oriented to the left or right, you run into this same problem, where you can't access menus by throwing your mouse to where the menu is; compiz again reserves space along the full length of the left/right edges of the screen.

I usually use my web browser in an unmaximized state but move it so that the scrollbar is just falling off the edge of the screen, so that I can flick my mouse to the right and use the scroll bar easily. This works in all OS's window managers, from OS X to XP to Fluxbox to Gnome and KDE.

However, with compiz enabled, moving my mouse to the very left or right of the screen (for scrollbars) makes it look like it's not focusing on the object. I think this has something to do with how AIGLX reserves space outside the desktop for buffering, or something like that.

This doesn't affect the top or corners of the screen however (plus the corners are reserved for things like Expose, which is fine)--only the left and right edges with compiz don't obey Fitt's law.

[Davidr-novell (davidr-novell)]

Forwarding an event from one top-level window to another is not possible. I
could send a fake event using XSendEvent that match the edge window event but
there's no guarantee that this will be handled correctly by the application.
Considering that the pointer isn't actually in the application window, such a
fake event might just be confusing for the application.

[Daniel Stone (daniels)]

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

[eppy 1 (choppy121212)]

Binary package hint: compiz

I usually use my web browser in an unmaximized state but move it so that the scrollbar is just falling off the edge of the screen, so that I can flick my mouse to the right and use the scroll bar easily. This works in all OS's window managers, from OS X to XP to Fluxbox to Gnome and KDE.

However, with compiz enabled, moving my mouse to the very left or right of the screen (for scrollbars) makes it look like it's not focusing on the object. I think this has something to do with how AIGLX reserves space outside the desktop for buffering, or something like that.

This doesn't affect the top or corners of the screen however (plus the corners are reserved for things like Expose, which is fine)--only the left and right edges with compiz don't obey Fitt's law.

I'll try and attach some pictures to show what I mean

[eppy 1 (choppy121212)]

Also, WITH COMPIZ ON if you maximize Firefox (or any other program that makes the scrollbar the screen's edge when maximized), then Fitt's law doesn't work anymore either. If you throw your mouse to the right edge or left edge (if you switch writing direction for diff. languages) of the screen then the scrollbar isn't selected; however, it should be.

It's kind of like how the start button pre-Windows XP never got hit if you threw your mouse to the bottom left corner; very annoying ;)

[eppy 1 (choppy121212)]

oops, somehow I added "project compizsettings (upstream)" to this bug, I didn't mean to do that; I was just trying to add the bug numbers in the Compiz and Beryl bug databases. I thought that clicking the +upstream button would do that but it didn't, sorry about that...

So here are the upstream bug numbers:
http://bugs.beryl-project.org/ticket/1889 Beryl "Beryl breaks Fitt's law with a pixel border at the right and left edges of the screen"
https://bugs.freedesktop.org/show_bug.cgi?id=10603 "Compiz breaks Fitt's law with a pixel border at the right and left edges of the screen"

[Travis Watkins (amaranth)]

Compiz creates input-only windows on the screen edges and corners for screen edge events.

[eppy 1 (choppy121212)]

I'll just add some info from my later filed duplicate Bug 123047-- this was filed for Gutsy, so it has some new information that didn't apply to Feisty (when this bug was filed), and also has higher priority since Compiz is now on by default.

"--fitt's law broken with compiz fusion, 1 pixel border at edge of entire screen, except the very corners:
 -can't select bottom of window list by throwing mouse
 -can't select scroll bar at the very right or left of the screen
 -can't select menu bar "applications" "places" or "system" by throwing
 mouse to the top of the screeen

 -only the UL, UR, BL, and BR corner areas still abide by fitt's law."

Bou at Ubuntuforums also created a graphic that shows the problem with Compiz in gutsy. (green=responseive, red=non-responsive)

[eppy 1 (choppy121212)]

The Ubuntuforums thread with some discussion on this topic: http://ubuntuforums.org/showthread.php?t=491886

[Dan Quade (danquade)]

Confirmed. This is extremely annoying. It makes Beryl/Compiz completely useless apart from showing off your cool OS.
A workaround for making left&right edges active again is to disable the Rotate Cube plugin, but that also makes the use of a 3D desktop kinda pointless.

[VF (vfiend)]

Yeah, this is really nasty and makes the window list bar a huge pain to use in Gutsy.

[Jonathan Jogenfors (etnoy)]

Agreed. Annoying bug.

[sam tygier (samtygier)]

also effects main gnome-panel menus in normail position. the top pixels of the menu widget don't work appart from the very top left pixel.

[Alexander Jones (alex-weej)]

The corners appear to be letting the clicks through. The two pixel edges of every border are unresponsive -- EXCEPT a 1 pixel square in each corner. Try moving your mouse to the Show Desktop button and watch as it highlights in the corner, then unlights, then highlights again as you move out. Nonsense!

[Travis Watkins (amaranth)]

This is caused by wall's default 'flip on window move' option. If you have screen edge options enabled compiz creates input-only windows on the screen edges to detect this.

[Martin Pitt (pitti)]

Michael, can you please take a look at this and delegate appropriately?

[Michael R. Head (burner)]

I would also point out that it's more than just the "flip on window move," because compiz paints a 2-3 pixel border on the left and right sides of the window even when the window is maximized that allows you to grab the window and pull it a little with a rubber band effect.

[Travis Watkins (amaranth)]

No, that's the regular window resize handle. Wobbly makes it move like it does.

[Michael R. Head (burner)]

Right, but my point is that it shouldn't be drawn when the window is maximized, since it leads to the same problem that many of the dupes of this bug report (i.e., fitt's law is broken so that it's quite hard to access the scrollbar when maximized).

[Jeff Waugh (jdub)]

The input-only windows should be only be created (or activated if the possibility exists) *during* window movement. This is a seriously uncool usability regression and should be cranked up higher than 'medium' priority if users are going to be stuck with this by default.

[Travis Watkins (amaranth)]

They're also used for events like activating scale when you move to a screen corner or scrolling the mouse wheel on the edge of the screen to change viewports. In this case we're only using them for window movement but that is not their primary use upstream so your idea for a fix would not work. We just have to setup our defaults to not use any window edges or corners and if people add those options back in later it's their own fault when they get this 'bug'.

[Chris Jones (cmsj)]

Can the events not be propagated to the windows below the input-only ones?
Window managers have been doing clever things with screen edges/corners for decades without issue.

[Dan Quade (danquade)]

To Chris Jones:
Good point.
I'm sure there is a way to avoid this problem and still keep the functionality.

What I'm not sure is if posting this to Ubuntu bug tracker can help much.
Maybe it would be better to start a thread about this on CompizFusion forums.

[Michael Vogt (mvo)]

 compiz-fusion-plugins-main (0.5.2-0ubuntu2) gutsy; urgency=low
 .
   * debian/patches/02_fix_edges.patch:
     - make the 1px border dynamic (thanks to onestone) (LP: #103306)

[Alexander Jones (alex-weej)]

This is marked as "fix released", but this affects the "cube" plugin too. On my up-to-date Gutsy right now, I can't grab anything on the right and left edges of my screen, still.

[Alexander Jones (alex-weej)]

Also, the bottom edges are still broken for anything other than the panel even in the default setup. Click events get eaten. Try this:

notify-send "bla" "bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla"

Now move your mouse to the bottom edge of the screen, over the notification that appears, and notice that although the mouse in event seems to happen nicely, clicks just don't happen.

(I disabled every single plugin I could in Compiz, and this was still happening.)

[Jeremy Nickurak (nickurak)]

Whatever "fix" was released is still not addressing this issue in Gutsy. Using the cube, I can't even open auto-hide panels on the screen edge. Can this bug please be re-opened?

[Travis Watkins (amaranth)]

The bug (and fix) are for the wall plugin. We're not that concerned with the cube plugin because you've explicitly chosen to use that.

[Jeremy Nickurak (nickurak)]

It would seem that if that plugin is included in a package and it doesn't work as expected, it's a bug. The fact that I chose to enable one included plugin over another doesn't change that, especially when the cube plugin is configured to not do anything special with the left/right edge except when moving a window.

[David Prieto (frandavid100-gmail)]

The bug has started to appear again in Hardy, after apparently being fixed in Gutsy final.

[Chris Jones (cmsj)]

confirming - this is back in hardy

[sfan (sfan)]

Also confirming - Annoying bug =(

[Denis Washington (dwashington)]

I submitted this bug upstream.

https://bugs.freedesktop.org/show_bug.cgi?id=14178

[Matt Zimmerman (mdz)]

This definitely seems to have regressed in Hardy

[LordSavage (lordsavage)]

Very annoying bug!

[Denis Washington (dwashington)]

I opened up a thread on the Compiz forums, it already seems to contain some good information about the cause:

http://forum.compiz-fusion.org/showthread.php?t=6885

[ogc (hackrez)]

This is annoying. Workaround is to disable desktop wall.

[Matthew Nuzum (newz)]

I have found what appears to be a perfectly suitable work around. If I turn off Desktop Wall but turn on Desktop Plane I get no perceivable loss of functionality with virtual desktops and I can now click all four edges of the screen.

Also, I have scale set to initiate the window picker when I move my mouse to the bottom right corner and it still works AND I can still click an icon like the trash can in the bottom right corner, even to the edges (though if I move my mouse to the bottom most, right most corner I of course get scale and clicking the trash doesn't work, which is what would be expected).

[Freedesktop-bugs (freedesktop-bugs)]

Dupe of #14178 (which, though filed later, seems to have more information and related links)

[Michael Vogt (mvo)]

This should be fixed with the upload of 0.6.99+git20080214-0ubuntu4 in hardy.

Cheers,
 Michael

[Oded Arbel (oded-geek)]

I'm using 0.7.0 on the 8.04 alpha, and the missing 2 pixels at the edge of the screen (top, bottom and sides) is still a problem.

[Travis Watkins (amaranth)]

He meant compiz-fusion-plugins-main 0.6.99+git20080214-0ubuntu4, which is not yet available in the archive. It also only fixes wall, which is already because if you use cube you're asking for this "feature", basically.

[Jeremy Nickurak (nickurak)]

I hate to beat a dead horse, but again, since the behavior of the bug is identical with the wall and cube plugins, and both are included in the package, how does the bug not apply to both plugins, aside from the fact that one plugin is enabled by default and the other is not? Or would it be more appropriate to file a seperate bug for this behavior under each effected plugin?

[Travis Watkins (amaranth)]

To be honest I don't much care about what happens with the cube plugin. As is we're carrying a patch against wall that doesn't forward port well and that we'll likely have to carry forever, I'd rather not have another one for cube. For cube you can just disable all the edge flip options (pointer, dnd, move) and that'll fix the problem too.

[sfan (sfan)]

Yeahh, with the new updates, the ubuntu default settings with desktop wall works now. Goood, thanks ubuntu devs.

[DanielRoesler (diafygi)]

I can confirm that this bug still exists on the Desktop Cube for Hardy Heron 8.04 beta LiveCD. When Wall is enabled, the bug is fixed. However, when Cube is enabled, the bug still remains.

[Nikola Borisof (nikola-borisof)]

I can also confirm the bug in 8.04 with Cube. It is annoying because i have gnome-panel on the right side of the screen set to autohide and this bug basically breaks the autohide.

[Kido (greasedbolt)]

This happens to me in 8.04 when Wall is enabled, but not when Cube is.

[John Boiles (johnaboiles)]

This happens to me in 8.04 using Cube.

[Nick Welch (mackstann)]

Woohoo!

I've finally come up with the magic bit of CSS to work around this:

hbox#browser { margin-right: -1px !important; }

(to anyone reading this that isn't sure what to do with that, copy/paste it into ~/.mozilla/firefox/<your profile>/chrome/userChrome.css)

This may be not be the absolute most correct solution (I think some other element has a border/margin/padding of 1 where it should be 0, but I couldn't track it down), but it fixes the problem for me perfectly.

[Nick Welch (mackstann)]

Sorry, that last comment was intended for #125734, although there seems to be a lot of confusion between these two bugs and maybe some people watching this one will benefit from it.

[Alexander Jones (alex-weej)]

And for those of us with proper browsers and proper applications that
don't run in browsers...

:P

[Emery De Nuccio (emery-denuccio)]

Confirmed in hardy 8.04. Sooo annoying. Please fix.

[DanielRoesler (diafygi)]

I can confirm this bug is fixed in Intrepid Ibex Alpha 5 with full updates (9/12/08) with the Human theme. Can anyone else confirm?

[DanielRoesler (diafygi)]

Unfortunately, I can confirm this bug pops up again in Intrepid beta with the Rotate Cube plugin enabled. It does not appear with the Wall plugin enabled or when only the Cube plugin is enabled. It occurs only when the ROTATE CUBE plugin is enabled. In fact, it is a two-pixel border on the sides that is inactive, not one.

Can anyone else confirm that Rotate Cube is the source of the problem?

[Jeremy Nickurak (nickurak)]

Um, what happened for this bug to be marked INCOMPLETE? Is there something we're missing in the various reports of this issue popping up?

[Nikola Borisof (nikola-borisof)]

I can confirm that the rotating Cube is the source of the problem. It only eats pixels on the left and the right side of the screen and not on the top or bottom. This bug makes playing games hard/impossible because the screen doesn't scroll. Please, please fix in 8.10.

Nikola

[DanielRoesler (diafygi)]

Jeremy Nickurak wrote:
> Um, what happened for this bug to be marked INCOMPLETE? Is there something
> we're missing in the various reports of this issue popping up?

This bug was previously marked Fix Released, but a fix wasn't released (as of 10/14/08). I also narrowed it down to the Rotate Cube plugin, but have no specific information about what exactly is the problem in the plugin itself.

[Matt Zimmerman (mdz)]

On Wed, Oct 15, 2008 at 01:35:45AM -0000, DanielRoesler wrote:
> This bug was previously marked Fix Released, but a fix wasn't released
> (as of 10/14/08). I also narrowed it down to the Rotate Cube plugin, but
> have no specific information about what exactly is the problem in the
> plugin itself.

"Incomplete" means that additional information is needed before the bug
report can be considered complete. An incomplete report cannot be worked on
by a developer.

Please see https://wiki.ubuntu.com/Bugs/Status to learn about bug status and
what it means.

The original problem reported in this bug is indeed fixed, so if there is a
different problem (specific to the rotating cube plugin), please report that
separately.

--
 - mdz

[DanielRoesler (diafygi)]

> The original problem reported in this bug is indeed fixed, so if there
> is a different problem (specific to the rotating cube plugin), please
> report that separately.

My apologies for marking Incomplete when I should have marked Confirmed. However, I don't believe that the original problem reported is fixed.

"However, with compiz enabled, moving my mouse to the very left or right of the screen (for scrollbars) makes it look like it's not focusing on the object."

Although the Wall plugin is fixed, the Rotate Cube plugin is not fixed. The Rotate Cube plugin is part of the compiz package (not main or extra), so enabling compiz should not create a problem with Fitt's law, no matter what plugin is used. On the other hand, if you think that enabling compiz means only the Normal or Extra Visual Effects option (and their corresponding plugins) is enabled, then this bug could be considered fixed and another report for the Rotate Cube plugin should be filed.

I think that since a problem exists in a package, it should be marked as such, even though the user cannot easily access the problem area. Obviously, you know more than I do, working for Canonical and all (and, btw, thank you thank you thank you for all you do to create an absolutely awesome distro), so I'll let you mark this as you see fit.

[Matt Zimmerman (mdz)]

On Wed, Oct 15, 2008 at 12:45:31PM -0000, DanielRoesler wrote:
> > The original problem reported in this bug is indeed fixed, so if there
> > is a different problem (specific to the rotating cube plugin), please
> > report that separately.
>
> My apologies for marking Incomplete when I should have marked Confirmed.
> However, I don't believe that the original problem reported is fixed.
>
> "However, with compiz enabled, moving my mouse to the very left or right
> of the screen (for scrollbars) makes it look like it's not focusing on
> the object."
>
> Although the Wall plugin is fixed, the Rotate Cube plugin is not fixed.
> The Rotate Cube plugin is part of the compiz package (not main or
> extra), so enabling compiz should not create a problem with Fitt's law,
> no matter what plugin is used. On the other hand, if you think that
> enabling compiz means only the Normal or Extra Visual Effects option
> (and their corresponding plugins) is enabled, then this bug could be
> considered fixed and another report for the Rotate Cube plugin should be
> filed.

I belive you that there is still a bug here; I am only asking that you file
it separately rather than reopen this old bug (which describes a problem in
a different plugin which has been fixed).

It becomes very difficult to keep track of issues when they are lumped
together in a single bug, as multiple actions need to be taken in the course
of fixing them and this cannot be reflected accurately in the status of a
single bug.

--
 - mdz

[DanielRoesler (diafygi)]

> I am only asking that you file it separately

Understood. Filed Bug #284158
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/284158

[Chris (chrisspelberg)]

I still have this problem on Intrepid with:
- NO Desktop Cube
- NO Rotate Cube
- YES Desktop Wall

Disabling Desktop Wall solves the issue but I need the functionality.

[cnom (cnom)]

I also see this on jaunty using only Desktop Wall. Disabling Edge Flipping cures it.

[positivek (anonyhole)]

I notice that at the top of the screen, maximized windows (their title bar) gets a single-left-click when I press click left, middle, right, or double-click. When you use the mouse scroll wheel in the same place, something like bug 277195 shows up. These are evidence for this bug existing in Ubuntu 9.04.

Reproduce these with the following variations of steps:

Scenario #1:
1. Make sure that no Gnome panel is on top (mine's on the left).
2. Maximize a "target window".
3. Bring a smaller window to front with focus, in front of the target window.
4. Put mouse at top pixel row of screen over a center portion of target window's title bar.
5. Try each of the following: Right-click; Middle-click; Double-click; Scroll up; Scroll Down.

Actual Result:
A6. With clicks, the target window is brought to front with focus as if it were left-clicked no matter what click or double click you did in step 5.
A7. With mouse scrolling in step 5, the desktop workspace gets switched (see bug 277195).

Expected Result:
E6. Window Menu should pop up for right-click; Window sent to back with middle; Window unmaximized with double.
E7. With srolling, nothing should happen. (Assuming title bar doesn't have anything mapped to scroll wheel events.)

Scenario #2:
Now repeat the above situation, replacing Step 2 with the following:
<Step 1 as above>
2a) Make sure Target window is unmaximized.
2b) Move target window to the top of the screen so it won't go any higher. Gnome (?) or Compiz (?) prevents the title bar from leaving the top of the screen. OK.
2c) Verify target window position by seeing the mouse cursor change to a resize arrow when at the top pixel row over the target window's title bar.
<Steps 3-5 as above>

Actual Result:
A6a: It works as expected, see E6 and E7 above.

Hope this helps.

[Travis Watkins (amaranth)]

Not sure if this should be a paper cut or not. In order to not have to maintain patches that break on every compiz update we have to disable features to fix this bug or wait for some large infrastructure work so compiz can know where the mouse is at all times without polling for its position.

[The Fiddler (stapostol)]

Since we can simply disable the ailing plugins, this is a paper cut candidate. Consider that:

a) This bug represents one of the worst UI design violations (breaking Fritt's law without any visual indication).

b) From the viewpoint of Compiz developers, this is not a bug (it's by design).

c) The average user doesn't have a chance to fix or work around this problem.

From my viewpoint, this has 'paper cut' written all over it. :)

[The Fiddler (stapostol)]

Sorry for the double-post, but consider that this bug has been bugging users since 2007 (and counting)! :)

[Bogdan Butnaru (bogdanb)]

Sorry for the spam, but what's “paper cut”?

-- Bogdan Butnaru

On Tue, Jun 16, 2009 at 7:31 PM, The Fiddler<email address hidden> wrote:
> Since we can simply disable the ailing plugins, this is a paper cut
> candidate.

[The Fiddler (stapostol)]

It's a bug-fixing effort going on for 9.10. There is a good writeup here:
http://arstechnica.com/open-source/news/2009/06/canonical-to-boost-ubuntu-usability-by-tackling-papercuts.ars

[Travis Watkins (amaranth)]

Disabling the plugins will disable workspace/viewport switching...

[David Siegel (djsiegel-deactivatedaccount)]

I cannot confirm this behavior for hundredpapercuts. Does this bug exist in Jaunty? I tried making Firefox full screen, and I can still scroll with my cursor all the way against the edge of the screen.

[J. Carlos Navea (loconet)]

> Does this bug exist in Jaunty?

loconet@loconet:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty

I am definitely still experiencing it in Jaunty. With Desktop Cube and Rotate Cube enabled, if I have Firefox maximized and throw my mouse cursor to the right side of the screen in order to click on the scroll bar (not the thumb), it will not scroll.

Disabling the "Rotate Cube" plug-in solves the issue.

[David Siegel (djsiegel-deactivatedaccount)]

Since the behavior does not occur when cube is not enabled, and cube is not enabled by default, this does not affect the default Ubuntu experience and cannot be considered a paper cut.

[The Fiddler (stapostol)]

This also occurs with the Desktop Wall plugin. Is this enabled by
default?

To verify, try clicking an application icon on the bottom panel when the
mouse is at the bottom of the screen.

On Wed, 2009-06-17 at 15:50 +0000, David Siegel wrote:
> Since the behavior does not occur when cube is not enabled, and cube is
> not enabled by default, this does not affect the default Ubuntu
> experience and cannot be considered a paper cut.
>
> ** Changed in: hundredpapercuts
> Status: Incomplete => Invalid
>

[Lightbreeze (nedhoy-gmail)]

I can't reproduce this bug with Desktop Wall in Jaunty.
I can interact with scrollbars and window list at screen edges flawlessly.

[Matt Zimmerman (mdz)]

On Wed, Jun 17, 2009 at 04:03:23PM -0000, The Fiddler wrote:
> This also occurs with the Desktop Wall plugin. Is this enabled by
> default?
>
> To verify, try clicking an application icon on the bottom panel when the
> mouse is at the bottom of the screen.

Yes, the Desktop Wall plugin is enabled by default, but I cannot reproduce
this bug with the default configuration.

--
 - mdz

[positivek (anonyhole)]

@ David Siegel, Lightbreeze, Matt Zimmerman

Notes:
* "borders of the screen" includes all borders, including the top.
* Top border has problems in default Compiz settings in Jaunty, as reported in my post (see below).

Additional notes:
* As noted, it seems that compiz already has some method of passing *only* the left-click event to windows underneath the top-border pixels.
* => Maybe there is an easy fix for this bug? That is, maybe the mouse-event pass-through was only partially implemented?

Regarding comment: "positivek wrote on 2009-06-07" ( https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/103306/comments/60 ).

[The Fiddler (stapostol)]

I have update to 9.04 and can confirm this bug only occurs at the top of the screen now.

[Lightbreeze (nedhoy-gmail)]

Its working for me at the top of the screen. I can imagine that would make using anything on the panel annoying :/

[The Fiddler (stapostol)]

After more testing, it seems that the top panel works correctly. On the other hand, if you move the top panel out of the way (say, place it on the left) and maximize a window, the top row of the screen will only accept left clicks. Right- and middle-clicks are eaten and the scroll wheel works as if it was over the desktop.

Confusing behavior, but probably not a paper cut (since it doesn't appear in the default configuration).

[Denis Washington (dwashington)]

@The Fiddler: The bhavior you mentioned doesn't have to do with the screen border issue. It is also triggered with a maximized window under a top panel when you move the pointer right on the line between the top panel and the window title. So this seems to be another bug (mayb of compiz' gtk-window-decorator?) unrelated to this one. (As it is there in the default configuration, it might actually apply as a papercut.)

[The Fiddler (stapostol)]

Interesting, I never tried to move the mouse at that exact row with the
top panel activated.

Is there a bug report for this? I searched launchpad, but my search-foo
is not strong enough.

[Юрий Чудновский (fqc)]

> I am definitely still experiencing it in Jaunty. With Desktop Cube and Rotate Cube enabled, if I have Firefox maximized and throw my mouse cursor to the right side of the screen in order to click on the scroll bar (not the thumb), it will not scroll.

> Disabling the "Rotate Cube" plug-in solves the issue.

I confirm it. There is more: in fullscreen wine (windows) apps (games) pulling mouse to screen edge (left or right) issue double mouse pointers - from app and from system. Even if no actions on mouse-to-edge is configured.

[Andruk (andruk)]

I can confirm Юрий Чудновский's report for Jaunty. This is a problem with Compiz activated and the Desktop Cube is enabled. Disabling the Desktop Cube fixes the problem. This is annoying; please fix soon.

[Freedesktop-bugs (freedesktop-bugs)]

Would it be useful to see how the package "brightside" deals with this issue without stealing mouse events? (Alternatively, as a workaround is it possible to dissable the edge-flipping, and use brightside to trigger a command that would flip the cube?)

[Nick Lutsiuk (nickl)]

I confirm it on Jaunty with Desktop Wall. How to reproduce:

The default settings of the edge flipping are (Pointer - Move - DnD) off - on - off. Default configuration works fine, but turning on edge flipping on Pointer and/or DnD results in mentioned behaviour.

[Travis Watkins (amaranth)]

That is expected and not fixable. In order to not eat mouse clicks at the borders and have those features work we'd have to poll for the mouse position rapidly which would be a somewhat small performance loss but a huge drain on battery life on laptops.

[Jeremy Nickurak (nickurak)]

How does the "brightside" package deal with this issue without eating mouse events? (Alternatively, as a workaround is it possible to dissable the edge-flipping, and use brightside to trigger a command that would flip the cube?)

[Travis Watkins (amaranth)]

The brightside app does exactly what we don't want to do, it polls for the mouse position 50 times a second.

[Andruk (andruk)]

Would it be possible to pass through any actions (eg: clicking) that aren't grabbed by Compiz? Somewhat like the notification system?

[Travis Watkins (amaranth)]

Upstream refuses to do such a thing since it is a hack and it would be too much of a change to maintain separately in Ubuntu.

[Andruk (andruk)]

How does the Desktop Wall plugin handle window moving? It seems to work the way I would expect the Desktop Cube (and Rotate Cube) would work.

So, is there a resolution in sight for this bug, or are we just stuck for awhile?

[scrawl (scrawl-deactivatedaccount)]

Please fix this. It's very annoying, and it MUST be fixable. Because, before my compiz update today, it worked (means it didn't eat mouse clicks at the border) with these Desktop Wall settings:
Mouse: No; Windows: Yes; DnD: Yes

But now it doesn't anymore. It's a very annoying bug :( I can't use compiz like that.

[Travis Watkins (amaranth)]

No, this has never worked. Please don't spread false information.

[Andruk (andruk)]

How would this feature work if it was implemented the "right" way?

[Hannes_S (x-hannesstruss)]

This still exists in Lucid 10.04, when "Edge Flip DnD" for the Desktop Wall Plugin is enabled.

[Peter Schulman (peter-schulman)]

Edge Flip DnD should have a warning text. I just spent the better part of an hour looking for a fix. FIrst blaming my gtk theme, then Gnome Panel settings, then Gnome, then finally stumbling upon the real culprit. Incredibly annoying!

[Joseph Price (pricechild)]

No cube enabled, "Edge Flip DnD" in Wall brings this annoying issue for me.

[Joseph Price (pricechild)]

Thinking further, and after reading everything above... this isn't "Fix Released". Should there be a separate bug report to track the bug on "Edge Flip DnD"?

[Travis Watkins (amaranth)]

No, it'll be closed as Won't Fix because it's not possible to fix.

[Julian J. M. (julianjm)]

Shoudn't it work when none of the flip options are enabled?

I really don't care if I cannot move a window to another desktop by dragging, but it kills me not to be able to click on a maximized window when the cursor is at the border of the screen.

[Julian J. M. (julianjm)]

Ok, to answer myself, here is a workaround for those using the cube+rotate plugins, and that don't want to lose those 2 pixels at each border.

1) Disable any flip edge feature in the rotate plugin
2) Run this cmds:
$ gconftool-2 -s -t string /apps/compiz/plugins/rotate/allscreens/options/rotate_flip_left_edge ""
$ gconftool-2 -s -t string /apps/compiz/plugins/rotate/allscreens/options/rotate_flip_right_edge ""
3) Enjoy your screen borders

You can also use gconf-editor if you want a gui.

[Anders Kaseorg (andersk)]

This may have resurfaced in natty as bug 638974.

[mehmet (mehmet-nrl)]

This bug still affects on ubuntu 12.10 with compiz 1:0.9.8.6-0ubuntu1.

[mehmet.nural (zxcq14)]

Please consider this bug. It's really frustrating