Bug 8127 - Mouse events from sensitive screen edges not reported to regular windows
Summary: Mouse events from sensitive screen edges not reported to regular windows
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: App/compiz (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: David Reveman
QA Contact: Xorg Project Team
URL: http://bugs.compiz.net/view.php?id=41
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-05 03:01 UTC by Ján Kľuka
Modified: 2018-06-12 19:07 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ján Kľuka 2006-09-05 03:01:20 UTC
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.
Comment 1 David Reveman 2006-10-11 15:44:01 UTC
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.
Comment 2 Daniel Stone 2007-02-27 01:33:26 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 3 Jeremy Nickurak 2008-03-02 08:19:30 UTC
Dupe of #14178 (which, though filed later, seems to have more information and related links)
Comment 4 Jeremy Nickurak 2009-09-15 20:59:46 UTC
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?)
Comment 5 Adam Jackson 2018-06-12 19:07:38 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.