Bug 25400 - Fedora 12: Mouse cursor trapped inside menu button
Summary: Fedora 12: Mouse cursor trapped inside menu button
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86-64 (AMD64) Linux (All)
: highest blocker
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
: 24059 (view as bug list)
Depends on:
Blocks: 27295
  Show dependency treegraph
Reported: 2009-12-02 11:30 UTC by djs
Modified: 2010-03-24 12:27 UTC (History)
13 users (show)

See Also:
i915 platform:
i915 features:

gzipped tar file with test application, source and executables. (302.90 KB, application/octet-stream)
2009-12-02 11:30 UTC, djs
no flags Details
tar file including source code and compile options for sample app (20.00 KB, application/x-tar)
2009-12-04 05:58 UTC, jcook5376
no flags Details
0001-dix-if-owner-events-is-true-for-passive-grabs-add-th.patch (3.07 KB, patch)
2009-12-15 19:56 UTC, Peter Hutterer
no flags Details | Splinter Review

Description djs 2009-12-02 11:30:31 UTC
Created attachment 31676 [details]
gzipped tar file with test application, source and executables.

Fedora 12, current as of 2009-12-02

Lesstif/Openmotif test application has a menu with one button, which should click up a dialog box. Clicking on the tiny triangle which indicates the pop-up is OK. Clicking anywhere else on the button traps the mouse cursor within the bounds of the button, with no means of escape other than switching to a console and killing the application.

Problem occurs when test application is compiled with Lesstif or Openmotif, and 32 bit or 64 bit.

When the test application is run across a network (ssh -X), the problem occurs if the display is a Fedora 12 system; problem does not occur if the display is an older Fedora 9 system (xorg-x11-server-Xorg-1.5.2-7.fc9.x86_64).

If/when a fix is available, get Fedora to approve and release it.
Comment 1 jcook5376 2009-12-04 05:58:21 UTC
Created attachment 31735 [details]
tar file including source code and compile options for sample app

Running into what I believe is the same issue:

Problem only occurs when trying to use Motif to display a popup menu.  Mouse
cursor gets locked inside of the parent window, and the popup menu is not

X server version:


Reproducible steps:
1.  Install openmotif (openmotif-2.3.2-5.fc12.i686)
2.  Run test app (compile options used in "README" file)
3.  right click on drawing area to bring up popup menu

Expected results: pop-up menu displays.

Additional info:
Problem does not occur using Fedora 11 (Kernel,
X-server version  We tried openmotif 2.3.0 and 2.3.2.  

Problem does not occur using X Toolkit methods of popup creation.  For example
XtMenuPopup().  Only when using motif, such as XmCreatePopupMenu().
Comment 2 jcook5376 2009-12-09 07:52:07 UTC
In some further testing, we've narrowed the problem down a bit to the XtGrabButton in RCPopup.C in the Xm library.  When using motif to create a popup, using, for example XmCreatePopupMenu, it seems to use XtGrabButton.  We found that if XtUngrabButton is called, the problem doesn't occur.

For example, a popup is created like so in example code:
menuRC = XmCreatePopupMenu(parent, (char*)(const char*)menuName, NULL, 0);

Then Ungrabbed immediately after:

for (i=0; i < ((_XmRowColumnRec *)menuRC)->row_column.postFromCount; i++)
    XtUngrabButton( ((_XmRowColumnRec *)menuRC)->row_column.postFromList[i], AnyButton, AnyModifier);

Now the pop-up works with mouse button 3 correctly.  I'm not sure what other effects this workaround would have, but it seems to be working for us so far.
Comment 3 Jim Ramsay 2009-12-11 03:48:10 UTC
As an additional datapoint, I'm experiencing the exact same trouble with
openMotif apps in Gentoo, xorg-server-1.7.3 on both 32-bit and 64-bit builds.

Before I upgraded, xorg-server-1.6.4 was *not* experiencing the problem with
exactly the same test app and openMotif library.  (I was using 'ddd' as my test
Comment 4 Jim Ramsay 2009-12-11 05:09:23 UTC
More info about my experiences in Gentoo, and my test cases with 'ddd':
Comment 5 Rémi Cardona 2009-12-11 08:11:25 UTC

This bug appeared with server 1.7. Obviously, a change in the input subsystem is making openmotif unhappy. Question is : which one is doing it wrong?

Comment 6 djs 2009-12-11 09:50:14 UTC
(In reply to comment #5)
> @Peter,
> Question is : which one is doing it wrong?

I think the fact that the bug affects Open Motif and Lesstif the same way is a clue.
Comment 7 Peter Hutterer 2009-12-15 17:29:14 UTC
from what I can tell by looking at the requests coming in, the test app in Comment #1 issues a passive grab in mode Sync.

the confine_to is part of that same grab, hence when the grab activates the cursor is confined to the window. the application never issues a AllowEvents request to the server, hence the events get queued up indefinitely.

which means either of two things:
- the app doesn't get an event that it used do get and thus doesn't trigger the AllowEvent request. In this case it's definitely the server that's at fault but the trick bit will be finding this event.
- the server does the right thing, the app just relies on previously broken behaviour.

still looking at the event stream on 1.6
Comment 8 Peter Hutterer 2009-12-15 19:56:02 UTC
Created attachment 32100 [details] [review]

Please try this patch, it seems to fix the problem for me.
Comment 9 jcook5376 2009-12-16 11:33:58 UTC
The patch seems to be fixing the issue for me as well.  Thanks!
Comment 10 Jim Ramsay 2009-12-16 13:15:09 UTC
Agreed, this patch also solves my issues with 'ddd' and a proprietary 'trace32' app that were both exhibiting this issue.
Comment 11 Peter Hutterer 2009-12-16 21:34:33 UTC
Thanks both of you for testing, I'll send it to the list and leave it in my local server for a while. stuff like this can have unexpected side-effects.

(In reply to comment #9)
> The patch seems to be fixing the issue for me as well.  Thanks!

If you would like your tested-by attached to the patch, I'd need your full name please (it's just a way to acknowledge your contribution).

Comment 12 Johannes Stezenbach 2010-02-02 07:28:18 UTC
I also have to use the proprietary trace32 app at work and was
afflicted by this bug. The patch works for me, so I would
like to encourage you to push it into mainline soon.
I'm using Debian unstable, Xorg 1.7.4, and just rebuilt the
Debian xserver-xorg-core package with the patch applied.

Bug #24059 "ddd blocks server" is also fixed by the patch.
Comment 13 Peter Hutterer 2010-02-02 14:37:20 UTC
*** Bug 24059 has been marked as a duplicate of this bug. ***
Comment 14 djs 2010-02-05 06:31:38 UTC
I have updated to 
xorg-x11-server-Xorg-1.7.4-6.fc12.x86_64 and

from the fedora-updates-testing repo and the problem is fixed for me. Sorry about not trying it sooner, but I didn't want to mess around with source code.
Comment 15 Johannes Stezenbach 2010-02-05 06:51:08 UTC
So Fedora has applied the patch in their package for testing
(xserver-1.7.4-owner-events.patch in
but please keep this bug open until the patch is in xorg git.
Comment 16 Jon Turney 2010-03-02 08:40:13 UTC
I've had some reports against XWin of similar problems where the input device is frozen due a passive grab, but the application never recieves the event to cause it to request a thaw.

See http://sourceware.org/bugzilla/show_bug.cgi?id=11301

Reproduction steps:

X -query solaris10vm
start CDE session
click on one of the uparrows on the panel to expand it, launch something
note that you can interact with that application, reize etc.
go back to click on the panel
input is now frozen

Note that I can also reproduce this problem with FC12 xorg-x11-xserver-Xorg-1.7.5-1, so this doesn't seem to be a XWin-specific problem.

Comment 17 Peter Hutterer 2010-03-03 22:07:33 UTC
commit cf72b5437d2d620521279077a29c5df6d0fbb576
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Feb 25 12:49:21 2010 +1000

    dix: Use DeliverGrabbedEvent for implicit passive grabs (#25400)
Comment 18 Jan de Groot 2010-03-08 13:53:04 UTC
This patch causes problems with several windowmanagers:

fluxbox, openbox and icewm are affected.
This was also brought up on the mailinglists:
Comment 19 Jon Turney 2010-03-08 14:06:02 UTC
Same issue with CDE session note in comment #16 is still present with current git master.

I did a little bit of debugging to confirm this is due to VCK/VCP getting frozen but never thawed.
Comment 20 Peter Hutterer 2010-03-08 18:58:13 UTC
patch is reverted in 1.7 nominations branch. I found that the original patch
(attachment 3 [details] [review] here) doesn't suffer from this issue, can you confirm this?
Comment 21 Jon Turney 2010-03-09 05:55:03 UTC
(In reply to comment #20)
> patch is reverted in 1.7 nominations branch. I found that the original patch
> (attachment 3 [details] [review] here) doesn't suffer from this issue, can you confirm this?

Not sure who this question is directed at, but for the avoidance of doubt, the CDE panel does not work correctly with either version of the patch applied.

(The behaviour is changed slightly vs. unpatched 1.7.5 in that the input freeze doesn't occur until the second interaction with the panel)
Comment 22 Martin von Gagern 2010-03-10 05:12:14 UTC
(In reply to comment #18)
> This patch causes problems with several windowmanagers:
> fluxbox, openbox and icewm are affected.

Affects KDE 3.5 app-switching using Alt+Tab: http://bugs.gentoo.org/308795
Comment 23 Jim Ramsay 2010-03-10 06:25:14 UTC
(In reply to comment #20)
> patch is reverted in 1.7 nominations branch. I found that the original patch
> (attachment 3 [details] [review] here) doesn't suffer from this issue, can you confirm this?

I can confirm that with the attachment 3 [details] [review] patch, fluxbox works just fine.
Comment 24 Martin von Gagern 2010-03-10 07:21:59 UTC
(In reply to comment #20)
> I found that the original patch doesn't suffer from this issue,
> can you confirm this?

I can confirm that attachment 32100 [details] [review] doesn't break KDE 3.5 for me. 
cf72b5437d2d620521279077a29c5df6d0fbb576 did, as I wrote in comment 22.
Comment 25 Peter Hutterer 2010-03-10 18:54:36 UTC
alrighty, thanks to all for testing. This still leaves CDE broken with the original patch applied, suggesting that we're not there yet.
Comment 26 Marko Macek 2010-03-10 23:59:58 UTC
Another, possibly related test:

1. flash plugin in firefox

2. right-click context-menu -> settings

3. try to click "close"

there are 3 possibilities:

1. works fine

2. replayed click ignored, second one works - if wm releases grab

3. click never works - if wm doesn't release grab
Comment 27 Marko Macek 2010-03-11 11:34:16 UTC
icewm also works fine again with reverted patch (problem was in task bar
not receiving replayed event -- because taskbar is also a toplevel window).

re: #26

I'm not sure this is an X server bug or a bug in firefox or flash plugin.

Proper behavior would be 1, but currently (with revert) it's 2 (metacity)
or 3 (current icewm which never releases the button grabs).
Comment 28 Chí-Thanh Christopher Nguyễn 2010-03-14 08:53:30 UTC
(In reply to comment #25)
> alrighty, thanks to all for testing. This still leaves CDE broken with the
> original patch applied, suggesting that we're not there yet.

If I understand correctly, CDE is broken in 1.7.5 already. So it does not matter whether the patch is applied or not in that regard.
But as it fixes other issues and does not worsen CDE's situation it might be good to apply it.
Comment 29 Peter Hutterer 2010-03-21 17:18:08 UTC
Keith just merged the patch into master.

commit 1c612acca8568fcdf9761d23f112adaf4d496f1b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Mar 17 14:32:38 2010 +1000

    dix: if owner-events is true for passive grabs, add the window mask (#25400)
Comment 30 Julien Cristau 2010-03-22 08:56:40 UTC
Closing the bug as the fix is in
Comment 31 Jon Turney 2010-03-24 12:27:39 UTC
As this bug has been resolved and the original issue fixed, I've created bug #27295 to track the problem with CDE sessions.

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.