Bug 543647 - Mouse cursor trapped in Lesstif menu button
Mouse cursor trapped in Lesstif menu button
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
12
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened, Triaged
: 542973 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-02 14:13 EST by CrystalCowboy
Modified: 2013-08-26 04:30 EDT (History)
20 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.7.99.902-2.20100319.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-11 23:26:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
gzipped tar file with test application, source and executables (302.90 KB, application/x-tar)
2009-12-02 14:13 EST, CrystalCowboy
no flags Details
Tar file with source of reproducible application and compile options (20.00 KB, application/x-tar)
2009-12-04 08:16 EST, jcook5376
no flags Details
Possible lessitf patch (175 bytes, patch)
2010-01-29 10:24 EST, Jon Ciesla
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 25400 None None None Never

  None (edit)
Description CrystalCowboy 2009-12-02 14:13:29 EST
Created attachment 375556 [details]
gzipped tar file with test application, source and executables

Description of problem: Mouse cursor gets trapped in *tif menu button


Version-Release number of selected component (if applicable): 1.7.1-7.fc12.x86_64


How reproducible: Completely, every time


Steps to Reproduce:
1. Install Lesstif or Openmotif
2. Run test application
3. Click menu button
  
Actual results: Mouse cursor is trapped within bounds of button, no means of recovery known short of killing the application from a console


Expected results: Dialog box pops up


Additional info: If application runs across a network (ssh -X), problem occurs if X server (display) is current Fedora 12. Does not occur if X server is Fedora 9. Version of X client (CPU) not relevant.
Problem does not occur if menu button does not have a pop-up.
Problem does not occur if one very carefully clicks on the tiny triangle indicating a pop-up, but happens when clicking elsewhere on the button.
Problem is consistent regardless of whether test application is Lesstif or Openmotif, 32 bit or 64 bit.
Other packages involved:
xorg-x11-server-common-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-0.95.2-1.fc12.x86_64
openmotif-2.3.2-5.fc12.x86_64
Comment 1 jcook5376 2009-12-04 08:16:59 EST
Created attachment 376073 [details]
Tar file with source of reproducible application and compile options
Comment 2 jcook5376 2009-12-04 08:17:19 EST
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().
Comment 3 jcook5376 2009-12-09 10:51:32 EST
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 4 Matěj Cepl 2009-12-09 16:59:30 EST
But all this is an openmotif issue, right? Reassigning.
Comment 5 jcook5376 2009-12-10 07:17:34 EST
After my last update I'm not convinced this is an openmotif issue, considering the problem stems from an Xt library call.
Comment 6 CrystalCowboy 2009-12-11 12:54:04 EST
(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.
Comment 7 CrystalCowboy 2009-12-14 08:51:32 EST
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
Comment 8 P.E. Aguera 2010-01-13 12:52:16 EST
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?
Comment 9 m 2010-01-25 19:06:28 EST
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
Comment 10 m 2010-01-25 19:08:11 EST
... reproduce: button-3 click on "nedit" text area
Comment 11 Bryce Wilkins 2010-01-26 03:04:58 EST
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
Comment 12 Alexei Podtelezhnikov 2010-01-28 14:32:11 EST
Bug 532621 is the same issue in grace.
Does anyone care, never mind Comment #4?
Comment 13 Jon Ciesla 2010-01-28 14:48:05 EST
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.
Comment 14 glend 2010-01-28 15:13:25 EST
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.
Comment 15 Jon Ciesla 2010-01-28 15:39:27 EST
Ok, I've got the relevant bits on my laptop, and will play with them tonight.
Comment 16 Hans de Goede 2010-01-28 15:54:52 EST
(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 17 m 2010-01-28 15:59:06 EST
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
Comment 18 Jon Ciesla 2010-01-28 16:14:40 EST
(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.
Comment 19 m 2010-01-28 16:37:28 EST
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 ???
Comment 20 Matěj Cepl 2010-01-28 17:36:50 EST
taking the bug back to libX11 for further investigation.
Comment 21 Jon Ciesla 2010-01-29 10:23:57 EST
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.
Comment 22 Jon Ciesla 2010-01-29 10:24:37 EST
Created attachment 387592 [details]
Possible lessitf patch
Comment 23 Jeremy Huddleston 2010-01-29 14:44:59 EST
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.
Comment 24 Jon Ciesla 2010-01-29 16:11:08 EST
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.
Comment 25 Kevin Paetzold 2010-01-29 16:13:06 EST
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"
Comment 26 m 2010-01-29 16:19:56 EST
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!
Comment 27 Kevin Paetzold 2010-01-29 16:30:07 EST
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;
Comment 28 Hans de Goede 2010-01-29 16:33:20 EST
(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!
Comment 29 Alexei Podtelezhnikov 2010-01-29 17:12:20 EST
So it could be libXt to blame... Adding Adam Jackson to CC.
Comment 30 Marco Beccuti 2010-01-30 12:56:10 EST
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.
Comment 31 Peter Hutterer 2010-01-31 22:50:39 EST
Upstream bug:
https://bugs.freedesktop.org/show_bug.cgi?id=25400
Comment 32 Peter Hutterer 2010-01-31 23:17:20 EST
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
Comment 33 Fedora Update System 2010-01-31 23:25:02 EST
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
Comment 34 Jon Ciesla 2010-02-01 10:59:34 EST
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?
Comment 35 Kevin Paetzold 2010-02-01 16:44:09 EST
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).
Comment 36 Fedora Update System 2010-02-01 20:25:38 EST
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
Comment 37 m 2010-02-02 06:40:05 EST
% 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.
Comment 39 m 2010-02-02 08:06:03 EST
Thanks. My two tests cases fixed after the update.
Comment 40 Phil Clayton 2010-02-02 08:43:54 EST
The x86_64 update fixes the issue we had on an OpenMotif app.  Nice one and thanks.
Comment 41 Alexei Podtelezhnikov 2010-02-02 10:29:02 EST
This patch is under review upstream. Acceptance by Fedora guarantees that it won't fall through the cracks. Thanks!
Comment 42 glend 2010-02-02 10:56:32 EST
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
------
Comment 43 CrystalCowboy 2010-02-05 09:36:52 EST
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.
Comment 44 Alexei Podtelezhnikov 2010-02-09 05:45:59 EST
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
Comment 45 Jeremy Huddleston 2010-02-09 11:59:54 EST
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.
Comment 46 Peter Hutterer 2010-02-09 19:08:41 EST
(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.
Comment 47 Davide Cesari 2010-02-16 05:05:22 EST
*** Bug 542973 has been marked as a duplicate of this bug. ***
Comment 48 Fedora Update System 2010-02-16 08:14:36 EST
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.
Comment 49 Alexei Podtelezhnikov 2010-02-27 12:33:27 EST
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.
Comment 50 Remke 2010-03-03 05:31:24 EST
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)
Comment 51 Fedora Update System 2010-03-08 22:50:41 EST
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
Comment 52 Remke 2010-03-09 02:03:09 EST
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
Comment 53 Remke 2010-03-09 03:33:28 EST
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
Comment 54 Peter Hutterer 2010-03-09 17:42:08 EST
reopening bug, comments here and in upstream bug report indicate that it's only fixed for some clients, not all.
Comment 55 Scott Robbins 2010-03-09 21:25:52 EST
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.
Comment 56 Fedora Update System 2010-03-10 01:44:22 EST
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
Comment 57 Fedora Update System 2010-03-11 23:26:13 EST
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.
Comment 58 Scott Robbins 2010-03-12 00:24:59 EST
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.
Comment 59 Scott Robbins 2010-03-18 05:55:54 EDT
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?
Comment 60 Fedora Update System 2010-03-19 00:32:59 EDT
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
Comment 61 Peter Hutterer 2010-03-19 00:45:45 EDT
F-13 had the upstream patch which has been reverted since. New patch added, same for rawhide.
Comment 62 Scott Robbins 2010-03-19 19:12:14 EDT
Great, thank you.  I just updated F14 and it now works like a charm.  Thanks again.
Comment 63 Fedora Update System 2010-03-23 19:37:36 EDT
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.
Comment 64 tobias.ewert 2013-08-26 04:30:21 EDT
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.
Comment 65 tobias.ewert 2013-08-26 04:30:58 EDT
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.

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