Mouse events which occur at those screen edges to which some action was assigned
are not forwarded to regular windows. This is not an problem if the action is
performed, but that is not always the case (see Additional Information).

If you happen to have a gnome panel at the sensitive edge which does not always
activate an action, you loose the convenient ability to access it and its
applets by throwing mouse cursor against the screen edge.

This was filed as a bug at bugs.compiz.net (see the URL), but is apparently an
upstream issue.

_______
Additional information

If you set some plugin to activate an action when you touch a screen edge, a 1
pixel thin input-only window is created along that edge. Mouse events in that
window then activate the action. Normally, the action is carried out, so it
should not be a problem if the input-only window eats up the mouse event instead
of (somehow) forwarding it to the other windows which touch the screen edge,
such as the panel.

Non-forwarding becomes an issue if the screen-edge action is not always
performed. This is the case of the rotate plugin. By default, rotate is set to
flip workspaces when you touch the left/right screen edge while moving a window
or performing a drag-and-drop (options edge_flip_dnd and edge_flip_move are
true). But if you just move the pointer to the edge, workspace flipping is
disabled by default (edge_flip_pointer is false). But the input-only edge
windows will eat mouse events anyway.

I can see three solutions:
* compiz should always forward events from the edge windows to normal windows, or
* every plugin which accepts edge events should forward them when it decides to
take no action, or
* such plugin should somehow instruct compiz to do forwarding in some cases.