Bug 543647

Created attachment 376073 [details]
Tar file with source of reproducible application and compile options

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.

But all this is an openmotif issue, right? Reassigning.

After my last update I'm not convinced this is an openmotif issue, considering the problem stems from an Xt library call.

(In reply to comment #4)
> But all this is an openmotif issue, right? Reassigning.  

I cannot agree with your assessment. Please note that this bug affects applications compiled with either Lesstif or Open Motif.

Today I spotted a difference in behaviour of my test application when compiled with lesstif vs. openmotif.

With openmotif, the problem occurs every time I click on the button, providing I do not click on the tiny triangle which indicates the pop-up menu.
openmotif-2.3.2-5.fc12.x86_64

With lesstif, clicking on the tiny triangle first somehow innoculates the button from the bad behaviour; after that I can click the button and have it work properly.
lesstif-0.95.2-1.fc12.x86_64

I have an old application (only binaries) that worked for years. It needs libXm.so.3 (openmotif 2.2.4).
The same problem occurs with the installation of an old version of openmotif (2.2.4).
This application ran on all previous Fedora releases.
The cursor is trapped ONLY when displaying on Fedora 12. Displaying on Fedora 11 or previous is OK.

running \ displaying |  F11 and older | F12
______________________________________________________
F11 and older        |   OK           | cursor trapped
F12                  |   OK           | cursor trapped

Does it help?

Reporting the same issue with several in-house motif applications.
Another way to reproduce: button-3 click on next text area.
Quite annoying bug: it makes the whole X desktop unusable, recover: switch to text console, kill process, switch back to X

... reproduce: button-3 click on "nedit" text area

Reporting same issue using AFNI, which has not experienced this bug when running under previous Fedora versions.  Discussion related to AFNI is here: http://afni.nimh.nih.gov/afni/community/board/read.php?f=1&i=31855&t=31855

Bug 532621 is the same issue in grace.
Does anyone care, never mind Comment #4?

I care, but have been otherwise occupied.  

Does anyone object to a build with a patch based on Comment #3?

Disclaimer:  I took ownership of lesstif to keep it in the distro, as I am the ddd maintainer which requires it.  Any assistance, patches, etc are welcome.

Besides the Grace bug report in comment 12, there is also this one that looks like the same thing.

https://bugzilla.redhat.com/show_bug.cgi?id=542869

Both those examples showed odd work-arounds by either using the shift-right click or turning on and off num-lock.

No objections here to progress. Thanks.

Ok, I've got the relevant bits on my laptop, and will play with them tonight.

(In reply to comment #13)
> Does anyone object to a build with a patch based on Comment #3?
> 

No objection from me, good luck with this (and thanks for working on it).

Comment 13: you mean a patch to lesstif? It looks like the bug should to go to xorg-x11, it's happening with openmotif too.

ps- shift-click / numlock tricks no help

(In reply to comment #17)
> Comment 13: you mean a patch to lesstif? It looks like the bug should to go to
> xorg-x11, it's happening with openmotif too.
> 
> ps- shift-click / numlock tricks no help    

In which xorg-x11 RPM?  I'm not sure I understand, but am open to ideas.

In the interim, all I can do is attempt to fix lesstif.  The alternative would be to patch all lesstif apps in Fedora.  I can't to anything about openmotif directly.

I have not checked how open/less tif have diverged, your patch might be something easy to retrofit so that would be welcomed altogether.
Now, unless it's something that has been hidden for long, it looks like the issue isn't with the motif toolkit(s) but the underlying layers.
I don't know enough about all the X/X11 details. But taking a guess, I would start with

% rpm -qf /usr/lib/libX11.so.6

libX11-1.3-1.fc12.i686

those people will have a better understanding than me if it's an X11 or xorg-x11-something ???

taking the bug back to libX11 for further investigation.

After some screwing around, I came up with a very short patch that corrects teh bug both for both of the programs attached to this bug, and seems to have no side effects other than a warning on the console, "Warning: Attempt to remove nonexistent passive grab" when this action occurs.  I also tried ddd with this patch, and observed no slaughtered kittens.

I can't guarantee that this isn't a horribly stupid patch, and it is admittedly a hack, but it seems to work.  I'll attach it for testing.

Created attachment 387592 [details]
Possible lessitf patch

That patch isn't very useful.

Can you please provide a larger argument to the -u option of diff when you make your patches.  The default is 3, so I'm not sure why you're lowering it.

I'm using 0 because that's the setting the current rpm expects when building packages, and that's where I'm using the patch.  I'm sorry if it's not as legible as we might like, but that's what I'm working with.

That said, I'm not sure how it isn't useful.  I recognize that it's a short patch, but I didn't make a big change, I just commented out a function call.

The patch does seem to work as advertised for xastir.  Have not yet noticed any
side effects other than the "Warning: Attempt to remove nonexistent passive
grab"

Comment24: a bit more context in your patch would allow trying it on openmotif. patch line number 1741/1744 on my openmotif/RowColumn.c lands in the middle of nowhere - Thanks!

This is the diff for the change I made for the patch in my local lesstif source
with a -U of 6.

--- /usr/local/lesstif-0.95.2/lib/Xm-2.1/RowColumn.c.b4kwp
+++ /usr/local/lesstif-0.95.2/lib/Xm-2.1/RowColumn.c
@@ -1736,15 +1736,16 @@
     XtListHead);

     DEBUGOUT(_LtDebug(__FILE__, NULL, "GRAB BUTTON: %p %s %d %x\n",
         realpar, XtName(realpar),
         RC_PostButton(new_w), RC_PostModifiers(new_w)));

-    XtGrabButton(realpar, RC_PostButton(new_w), RC_PostModifiers(new_w),
+/*    XtGrabButton(realpar, RC_PostButton(new_w), RC_PostModifiers(new_w),
    True, ButtonReleaseMask, GrabModeSync, GrabModeSync,
    XtWindow(realpar), _XmGetMenuCursorByScreen(XtScreen(new_w)));
+*/
 }

 static void
 MenuProcEntry(int proc, Widget w,...)
 {
     va_list arg_list;

(In reply to comment #24)
> I'm using 0 because that's the setting the current rpm expects when building
> packages, and that's where I'm using the patch.  I'm sorry if it's not as
> legible as we might like, but that's what I'm working with.
> 

Erm, that is simply note true. rpm expects patches to apply without fuzz, which
means that if any of the surrounding lines (the context) ever change, you need to
re generate the patch. Which is a good thing, as then you can verify it is
still valid despite the changes.

Please do not generate patches with less then 3 lines of context, thank you!

So it could be libXt to blame... Adding Adam Jackson to CC.

I'm maintaner of the tool GreatSPN (http://www.di.unito.it/~greatspn), a well-known tool for system evaluation based on the Petri Net formalism and released by the University of Torino; unfortunatly our tool has the same problem with fedora 12.

Indeed the tool uses openmotif for the GUI, and each time that I click the right mouse button then all is frozen.
I can only move the mouse inside the whiteboard of the tool GUI.

Could you help me to solve the problem?

If it is necessary I can send you the code.
Thanks.

Upstream bug:
https://bugs.freedesktop.org/show_bug.cgi?id=25400

This is a server issue, reassigning to xorg-x11-drv-server. Fix available in build xorg-x11-server-1.7.4-6. 

http://koji.fedoraproject.org/koji/taskinfo?taskID=1955642

xorg-x11-server-1.7.4-6.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.4-6.fc12

Thanks to everyone for helping get this sorted out.

Hans, my apologies, I either got bad advice or totally misread what I saw when the default fuzz changed.  I currently use diff -U0 file.old file > name-of.patch, should it now be diff -U3 file.old file > name-of.patch?

I downloaded and installed the packages from the fix above (in xorg-x11-server-1.7.4-6.fc12).  So far so good (seems to work fine).

xorg-x11-server-1.7.4-6.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1365

% yum --enablerepo=updates-testing install xorg-x11-server
Loaded plugins: changelog, presto, refresh-packagekit, versionlock
Setting up Install Process
No package xorg-x11-server available.
Nothing to do

% yum clean all

repeat: same thing

% yum --enablerepo=updates-testing update xorg-x11*

brings

xorg-x11-server-Xorg-1.7.4-3.fc12.i686
xorg-x11-server-common-1.7.4-3.fc12.i686

so no 1.7.4-6 yet. createrepo still working its way up? Will check again later.

You can install this fix with these 2 packages:

http://kojipkgs.fedoraproject.org/packages/xorg-x11-server/1.7.4/6.fc12/i686/xorg-x11-server-common-1.7.4-6.fc12.i686.rpm
http://kojipkgs.fedoraproject.org/packages/xorg-x11-server/1.7.4/6.fc12/i686/xorg-x11-server-Xorg-1.7.4-6.fc12.i686.rpm

Thanks. My two tests cases fixed after the update.

The x86_64 update fixes the issue we had on an OpenMotif app.  Nice one and thanks.

This patch is under review upstream. Acceptance by Fedora guarantees that it won't fall through the cracks. Thanks!

Our test cases also work now under AFNI, so we're happy. Thanks.

By the way, I found this mention from an old (2004) Lesstif thread of a warning of impending doom from the AddPopupHandlers function handling of the right-button click...


It appears that in rowcolumn.c, AddPopupHandlers does an XtButtonGrab() to
add a passive button grab on the menu's parent for the right mouse button.
This means that when the right button is pressed, the server will do a
pointer grab for the client.  It is then the client's responsibility to
release the pointer grab, which it usually does when the menu pops down.

However, destroying the menu does not ungrab the button.  The net effect is
that once you've destroyed the menu, clicking the right mouse button on the
parent, causes a pointer grab which the client ignores and never ungrabs, so
you're stuck.


 -- Dave Williss
------

I have installed
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 repository and the problem seems to be fixed for my application, using either lesstif or openmotif.

Thank you.

It doesn't look like this patch is getting proper attention upstream.
The requested review [1] was never completed, nor has it been applied to any branch. Have that plane landed [2]?  Why is this patch missing 1.7.5 train?

[1] http://lists.x.org/archives/xorg-devel/2010-January/004941.html
[2] http://lists.x.org/archives/xorg-devel/2010-January/005230.html

Peter sent a pull request to get it into master:

http://lists.x.org/archives/xorg-devel/2010-February/005325.html

That is required before it can be cherry-picked into the 1.7-nominations.  It has not been merged into master likely due to lack of review.  I'm not confident in reviewing the patch since I'm not extremely familiar with this area of the server.

(In reply to comment #44)
> It doesn't look like this patch is getting proper attention upstream.
> The requested review [1] was never completed, nor has it been applied to any
> branch. Have that plane landed [2]?  Why is this patch missing 1.7.5 train?

as Jeremy said, a Reviewed-by tag is missing. the patch, similar to the other ones in that second pull request, is rather tricky to review as it is not obvious to those not directly working on these bits. I've pinged Keith multiple times to get a review and a pull for these. Until they are pulled into master, we can't push them into 1.7.5 and it will have to remain a patch in the fedora repo.
The patch won't get lost though, don't worry.

*** Bug 542973 has been marked as a duplicate of this bug. ***

xorg-x11-server-1.7.4-6.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

The reworked patch
http://lists.x.org/archives/xorg-devel/2010-February/005845.html
included in
http://koji.fedoraproject.org/koji/buildinfo?buildID=158522
works well.

schuurma@bhw185:~$ rpm -qa |grep xorg-x11-server
xorg-x11-server-Xvfb-1.7.4-6.fc12.i686
xorg-x11-server-utils-7.4-13.fc12.i686
xorg-x11-server-common-1.7.4-6.fc12.i686
xorg-x11-server-Xorg-1.7.4-6.fc12.i686

Problem stil exists ...
~remke
(https://bugzilla.redhat.com/show_bug.cgi?id=505853)
(https://bugzilla.redhat.com/show_bug.cgi?id=541049)

xorg-x11-server-1.7.5.901-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.5.901-4.fc12

I have installed:
xorg-x11-server-Xorg-1.7.5-5.fc12.i686

;(( same problem, using gnome -> keyboard stops working (mouse still works)
Linux bhw185 2.6.31.12-174.2.22.fc12.i686 #1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686 i386 GNU/Linux

I have installed:
xorg-x11-server-Xorg-1.7.5-5.fc12.i686

;(( same problem, using gnome -> keyboard stops working (mouse still works)
Linux bhw185 2.6.31.12-174.2.22.fc12.i686 #1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686 i386 GNU/Linux

reopening bug, comments here and in upstream bug report indicate that it's only fixed for some clients, not all.

Latest xorg updates to 1.7.5-5 breaks fluxbox.  (Works in openbox.)
A fix is available at https://admin.fedoraproject.org/updates/xorg-x11-server-1.7.5.901-4.fc12 which works for me.

xorg-x11-server-1.7.5.901-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.5.901-4.fc12

xorg-x11-server-1.7.5.901-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

This one has solved the fluxbox issues mentioned in my comment #55.  I haven't updated Rawhide in a day or two, but hopefully, the fixes in this latest version got pushed there too.  

Thanks for the fix.

This is working in F13.  However, after updating to Rawhide, once again I have the same fluxbox issues.  Did the patched version make it to F13 but not F14?

xorg-x11-server-1.7.99.902-2.20100319.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.99.902-2.20100319.fc13

F-13 had the upstream patch which has been reverted since. New patch added, same for rawhide.

Great, thank you.  I just updated F14 and it now works like a charm.  Thanks again.

xorg-x11-server-1.7.99.902-2.20100319.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

We still have this Problem on a plain RHEL6.3 installation, using a pen
of a WACOM Display. GTK works fine. After opening a menu of openmotif with a pen or a mouse, then moving the cursor with the pen to a different position, the display cannot be controlled unless esc is pressed.

We still have this Problem on a plain RHEL6.3 installation, using a pen
of a WACOM Display. GTK works fine. After opening a menu of openmotif with a pen or a mouse, then moving the cursor with the pen to a different position, the display cannot be controlled unless esc is pressed.