Red Hat Bugzilla – Bug 102761
Xemacs becomes unresponsive, takes down mozilla UI response
Last modified: 2015-01-07 19:06:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030530
Description of problem:
Occasionally mozilla's UI windowing, text, and mouse reponses will cease to
work. Tabs will stop loading or displaying. Text boxes no longer have a
cursor. Mozilla becomes unusable at this point, but closing it does not work.
A killall is required. However, on a fresh restart of mozilla, the problem
The problem appears to be with Xemacs. Looking at its window, it is no longer
displaying anything (blank window with window title and nothing being displayed
in the window). Xemacs will not respond or shutdown cleanly. Kill is required.
Upon killing xemacs, all windowing tasks in Mozilla start to respond normally.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Load xemacs and mozilla
2. Leave xemacs running and use mozilla, occasionally bouncing back to the
3. Problem will eventually crop up
If I may suggest a theory, I believe this has something to do with how Xemacs
relates to the X-cursors. I have noted bug #90614 happening on my system as
well (NVidia card). Considering that this problem and the cursors problem both
hang on xemacs, there is probably something in the way it makes calls to the
window manager and xserver that is hanging some system.
Thanks for the report. This also sounds somewhat reminiscent of bug 90386
Could I ask you to try with the current xemacs package in rawhide/Severn
to see if the problem still occurs with it (it no longer uses lesstif)?
I upgraded to the Severn Xemacs packages (which required a bunch of other stuff
to including glibc).
I noticed that the Xemacs cursor problem still persists--but it is much more
manageable. The cursor will sometimes remain as the xemacs cursor when outside
xemacs, but as soon as it is moved or a window is clicked on, it changes.
Additionally, before when the cursor was messed up (say, set to a stopwatch),
clicking on the desktop switcher would not work or would not act as expected.
This no longer happening.
So it looks like the cursor logic is still not completely locked down, but some
of the problems that went with it appear to have been resolved. I will see if
it locks up the windowing functions in mozilla--but so far so good.
Good to hear that is working somewhat better at least.
ICBW but I think the cursor problem and the hanging are two
quite separate problems.
Please re-open this report if you're still seeing problems. Thanks.
*** This bug has been marked as a duplicate of 90386 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.