Red Hat Bugzilla – Bug 462678
Applications does grab without doing ungrab, locking the display
Last modified: 2010-10-23 00:36:49 EDT
Created attachment 317049 [details]
Test program to trigger the bug
Description of problem:
There is a bug in OpenMotif regarding handling of Grab/Ungrab events that have been queued while the application is busy doing something else. The bug is that OpenMotif currently will make the Grab event succeed (by resetting the time to current time if first call fails), while it will allow the Ungrab event to fail; the result is that the application wrongly ends up in a Grab state.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile the attached test program: cc motifhang.c -o motifhang -lXm
2. Run it: ./motifhang
3. Press the File->Delay menu entry
4. Within 5 seconds, press the File menu button twice (or any EVEN number of times)
5. After the 5 seconds have passed, press the Click button
The display is now effectively locked. The cursor is in the menu mode.
(Kids, if you try this at home, make sure you have the AllowClosedownGrabs and/or AllowDeactivateGrabs options activated in your X server first. :-)
Nothing special should happen.
This is recently fixed in upstreams: http://bugs.motifzone.net/show_bug.cgi?id=1328 (The motifzone bugzilla does not seem to be in the menu for external bug references.) What we need is that fix applied to the RHEL package.
There will be an OpenMotif rebase to 2.3.1 for EL-5.3. The 2.3.1 version already contains the fix.
See comment #1, proposing for RHEL-5.3 with exception and granting Devel ACK.
Read ya, Phil
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.