Bug 25400

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.