Bug 184143 - Double-Click does not work with Metacity Window Manager and Motif with certain WM preference settings
Double-Click does not work with Metacity Window Manager and Motif with certai...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: metacity (Show other bugs)
4.0
All Linux
high Severity high
: ---
: ---
Assigned To: Søren Sandmann Pedersen
: Reopened
Depends On:
Blocks: 234251
  Show dependency treegraph
 
Reported: 2006-03-06 14:59 EST by Stephen G. Brickles
Modified: 2014-06-18 05:08 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0769
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 10:59:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen G. Brickles 2006-03-06 14:59:23 EST
Description of problem:
Double-Click mouse clicks do not work in Motif-based applications under
GNOME/Metacity when the "Select Windows when the mouse moves over them"
preference is enabled.  The application where this was observed is a major Cadence
Motif-based application, however the bug is reproducible with a simple
Xt/Motif program available at the link below.

Version-Release number of selected component (if applicable):

Test machine has latest Redhat 4.0 updates installed.

Metacity 2.8.6-2.8
libgnome 2.8.0-2
libgnomeui 2.8.0-1
gtk2-2.4.13-18

How reproducible:

Compile test program below and execute under GNOME/Metacity Window Manager

Steps to Reproduce:
1. Launch test program
2. Single Click on displayed button and observer terminal output
3. Double Click on displayed button and observe that terminal still displays
   the words "Single click"
4. Perform same tests after disabling "Select Windows when the mouse moves over
them"
and observe the double-clicking on the button produces the words "Double click"
in the terminal window.

Additional info:
Test program is available at

http://www.ecs.csun.edu/~renzo/cs585/Heller.book/Volume6/ch11/multi_click.c

Compile as:
 gcc -o mc -c multi_click.c -lXm -lXt -lX11 -L/usr/X11R6/lib
Comment 1 Søren Sandmann Pedersen 2006-09-06 15:35:22 EDT
For official Red Hat Enterprise Linux support, please log into the Red Hat
support website at http://www.redhat.com/support and file a support ticket,
or alternatively contact Red Hat Global Support Services at 1-888-RED-HAT1
to speak directly with a support associate and escalate an issue.
Comment 9 RHEL Product and Program Management 2006-11-06 10:06:40 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 15 Alan Matsuoka 2007-04-10 14:19:25 EDT
Shouldn't this be Soren ?
Comment 17 Alan Matsuoka 2007-04-10 19:02:27 EDT
Raising the priority of the BZ as requested.
Comment 20 Søren Sandmann Pedersen 2007-04-12 12:12:15 EDT
Some preliminary results:

- The gnome bug referenced is not the same as this one

- This bug is caused by spurious crossing events that causes Xt to think
  that the pointer left the button between the two clicks.

- My guess is that this is related to metacity having a passive grab on
  the window in focus follows mouse mode.
Comment 21 Søren Sandmann Pedersen 2007-04-12 17:07:44 EDT
This is a pick-your-poison situation.

Metacity can either have an XGrabButton on the window, or not. If it does, then
crossing events will be generated, and we will see this bug, which is
essentially gnome bug 102209 [1]. If it doesn't, then it has no way of
intercepting clicks on the window which means that it can't focus or raise the
window in response to clicks. 

The reason it works in click-to-focus is that in that case metacity drops the
XGrabButton when the window is focused. We could do the same in sloppy mode, but
then a user could alt-tab focus some other window and then have no way to focus
the window again, except mousing out and back in. See gnome bug 115072 [2].

I believe any window manager will have the same problem, and that the only real
fix is to add an extension to X that would allow XGrabButton without clicks
causing crossing events.

Do we know what window manager (and preferences) the customer is using now?

References:

[1] http://bugzilla.gnome.org/show_bug.cgi?id=115072

[2] http://bugzilla.gnome.org/show_bug.cgi?id=102209
Comment 22 Stephen G. Brickles 2007-04-12 17:21:57 EDT
We have also seen this same double click issue in KDE when the "Click raise
active Window" checkbox is set.  If you were to provide a checkbox in Metacity
to disable this click-raise-active feature in "Focus follows Mouse" mode, I
think you could get around the issue based on what you are saying ?  I am not
sure I understand why this problem is only present in Motif-based applications -
does this apply to all widget libraries that use Xt ?
Comment 23 Søren Sandmann Pedersen 2007-04-12 17:42:47 EDT
Yes, to be more specific, I think it may be possible to make this work when the
(hidden) raise_on_click preference is set to FALSE. Ie. the poisons you get to
pick between are:

- windows will not be raised on clicks in the middle of the window (only on the
frame).

or

- double clicks implemented like this will not work.

The reason this is only a problem in motif is just an artefact of this
particular way of doing double clicks. They keep a time stamp in the button
which is reset when a crossing event is seen; other toolkits may just compare
the latest two timestamps and treat it as a double click if they are close enough.

It may be possible to change the Motif application to ignore crossing events
that have "mode == NotifyGrab". I don't know if that's feasible. Is the
application statically or dynamically linked to motif? Do you have the source
for it?
Comment 24 Stephen G. Brickles 2007-04-12 17:54:05 EDT
Unfortunately not.  This is a major Cadence software application which is being
used at my company for chip design.  This piece of software has been around for
ever.  I doubt I could persuade them to re-write the application !!  Cadence
conceded that the bug was present in Redhat 4 but defaulted to you guys to fix
it.  The double-click operation is fairly crucial to the operation of the tool.
 What's odd is that I believe this double-click worked in the version of
Metacity which came with Redhat 3.
Comment 25 Søren Sandmann Pedersen 2007-04-13 10:27:25 EDT
The Metacity that came with RHEL 3 did not allow raise on click in mouse-focus
mode, so it didn't have a passive grab on un-focused windows. I believe the
problem is fundamental and will exist in some form in all window managers.
Basically, either

- raise-on-click in mouse mode doesn't work

or 

- applications will see spurious crossing events (causing problems including,
but not limited to, this double click one).

I can change metacity so that the double-click problem goes away when the
preference /apps/metacity/general/raise-on-click is set to FALSE. 
Comment 26 Søren Sandmann Pedersen 2007-04-13 11:06:13 EDT
... so it didn't have a passive grab on *focused* windows ...
Comment 27 Søren Sandmann Pedersen 2007-04-13 11:07:46 EDT
oh, and in RHEL 4 the preference is called
/apps/metacity/rhel3_workarounds/raise_on_click/
Comment 29 Stephen G. Brickles 2007-04-13 13:32:24 EDT
>I can change metacity so that the double-click problem goes away when
>the preference /apps/metacity/general/raise-on-click is set to FALSE.

Sounds good to me - but it would be nice to have this option in the Window
Manager Preferences GUI as well as in gconf 
Comment 32 ritz 2007-04-16 15:37:28 EDT
thanks, and is the patch is same as that from gnome bugzilla #115072 [1] ?
If otherwise, would it be possible for you to provide a patch/test srpm ?

[1] http://bugzilla.gnome.org/show_bug.cgi?id=115072
Comment 35 RHEL Product and Program Management 2007-05-09 06:45:10 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 43 errata-xmlrpc 2007-11-15 10:59:00 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0769.html

Note You need to log in before you can comment on or make changes to this bug.