Created attachment 31676 [details] gzipped tar file with test application, source and executables. Fedora 12, current as of 2009-12-02 xorg-x11-server-common-1.7.1-7.fc12.x86_64 xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64 xorg-x11-utils-7.4-7.fc12.x86_64 xorg-x11-server-utils-7.4-13.fc12.x86_64 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.
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 displayed. X server version: 1.7.1-9.fc12.i686 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 2.6.29.6-217.2.16.fc11.i686.PAE, X-server version 1.6.3.901). 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().
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.
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 application).
More info about my experiences in Gentoo, and my test cases with 'ddd': https://bugs.gentoo.org/296514
@Peter, 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? Thanks
(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.
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
Created attachment 32100 [details] [review] 0001-dix-if-owner-events-is-true-for-passive-grabs-add-th.patch Please try this patch, it seems to fix the problem for me.
The patch seems to be fixing the issue for me as well. Thanks!
Agreed, this patch also solves my issues with 'ddd' and a proprietary 'trace32' app that were both exhibiting this issue.
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).
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.
*** Bug 24059 has been marked as a duplicate of this bug. ***
I have updated to xorg-x11-server-Xorg-1.7.4-6.fc12.x86_64 and xorg-x11-server-common-1.7.4-6.fc12.x86_64 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.
So Fedora has applied the patch in their package for testing (xserver-1.7.4-owner-events.patch in ftp://download.fedora.redhat.com/pub/fedora/linux/updates/testing/12/SRPMS/xorg-x11-server-1.7.4-6.fc12.src.rpm), but please keep this bug open until the patch is in xorg git.
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.
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)
This patch causes problems with several windowmanagers: http://bugs.archlinux.org/task/18598 fluxbox, openbox and icewm are affected. This was also brought up on the mailinglists: http://www.mail-archive.com/xorg-devel@lists.x.org/msg05737.html
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.
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?
(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)
(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
(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.
(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.
alrighty, thanks to all for testing. This still leaves CDE broken with the original patch applied, suggesting that we're not there yet.
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
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).
(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.
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)
Closing the bug as the fix is in 1.7.99.902.
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.