Bug 111225

Summary: maximizing causes xemacs to freeze up
Product: [Fedora] Fedora Reporter: Yaron Minsky <yminsky>
Component: xemacsAssignee: Ville Skyttä <ville.skytta>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: Christian.Iseli, disnel, fla_2, hp, jonabbey, maayant, mjs, petersen, sylvain.ferrand
Target Milestone: ---Keywords: MoveUpstream
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 21.5.28 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-02 17:57:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 173247    
Description Flags
xemacs- none

Description Yaron Minsky 2003-11-30 20:32:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
When you try to maximize xemacs, it chews up the processor and freezes
up.  It doesn't even get to the point of redrawing the scrollbars in
the right place.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run xemacs (this still works with "-q", so it's not init file specific)
2. Click on the maximization button
3. Watch as xemacs happily eats all of your CPU and ignores your
keystrokes.  Your cursor will also start flashing.

Additional info:

I'm apparently not the only one to notice this one:


Comment 1 Jens Petersen 2003-12-09 05:31:18 UTC
Unfortunately I haven't received any feedback from upstream about this.

Comment 2 Jens Petersen 2003-12-09 05:33:22 UTC
Oh, I should add that it seems be be metacity specific afaict:
eg it doesn't seem to happen under KDE for example.

Havoc, do you have any comments/ideas about this?

Comment 3 Jens Petersen 2004-01-15 05:54:33 UTC
XEmacs upstream are aware of the issue.

Comment 4 Jens Petersen 2004-02-05 03:02:09 UTC
Still occurs with 21.4.15.

Comment 5 Jens Petersen 2004-06-06 17:03:43 UTC
*** Bug 111896 has been marked as a duplicate of this bug. ***

Comment 6 Havoc Pennington 2004-06-06 18:36:54 UTC
Regular GNU Emacs used to rely on the WM implementing a short-circuit,

  1. Emacs asked for size WxH
  2. Metacity assigned it WxH
  3. Emacs would ask for WxH again
  4. If Metacity assigned WxH back as requested, the loop continued;
     GNU Emacs requires the WM here to do nothing if WxH is already
     the current size

Basically GNU Emacs was on crack and always sent another "please
resize me" request in response to a "you have been resized" event.

Maybe XEmacs has some similar weirdness.

The way the specs are written this almost certainly is technically
XEmacs's fault, since the WM is given full authority over sizes and
apps are required to accept anything. However there may be a simple
workaround in the WM.

Comment 7 Aleksandar Milivojevic 2004-11-22 15:18:00 UTC
I'd just add that clicking "unmaximize" (or hitting alt-f5) will
restore the window to wrong size (vertical size will be "unmaximized"
size, but horizontal size will be "maximized" (full screen widht)
size).  Also, hitting "unmaximize" will get xemacs out of the infinite

Comment 8 Jens Petersen 2005-02-25 01:05:25 UTC
I believe this was recently fixed in the 21.5 beta series.,
but didn't get round to backporting the fix...

Comment 9 Tim Niemueller 2005-06-06 12:36:09 UTC
Can we expect some fix in the near future?

Comment 10 Ville Skyttä 2005-06-06 18:36:19 UTC
From XEmacs 21.4.17 release notes, http://www.xemacs.org/Releases/21.4.17.html

  * Fix: Make window maximization work under Metacity.

XEmacs 21.4.17 is already in Extras for FC4 and later.  Jens can answer for
earlier FC versions (Jens, feel free to set the status of this bug as you wish.
 As far as I'm concerned, this is CLOSED (RAWHIDE|CURRENTRELEASE) but then
again, I'm a KDE user so I haven't even experienced the issue... it would be
nice if someone could verify whether this is indeed fixed in 21.4.17 or not).

As a side note, the FE4/devel xemacs-21.4.17 and latest xemacs-sumo should be
buildable on earlier distro versions.  I'm running such rebuilt ones on FC3,
they work fine for me.

Comment 11 Jens Petersen 2005-06-07 07:28:14 UTC
No, it is not fixed yet in xemacs-21.4.17-3 afaict.

Comment 12 Havoc Pennington 2005-06-07 23:41:03 UTC

Looks like if Emacs doesn't get its requested size, it just keeps asking for it.

Comment 13 Ville Skyttä 2005-06-10 12:24:31 UTC
Ok, got a chance to test, and indeed this is not completely fixed.  Damn.

I cannot get XEmacs 21.4.17 to freeze though.  It (and X) does consume quite a
bit of CPU when XEmacs tries to maximize (apparently repeatedly trying to
resize, buffers tab flickers etc), but I can use it otherwise during that state.
 The problem mentioned in comment 7 happens also in KDE (where the repeated
resize effect does not occur), but with slightly different results.  Anyway,
unmaximizing does not work.

BTW, the patch from the message Havoc pointed out is applied in 21.4.17, so this
is something in addition to that.  Will try to have a look next week(ish).

Comment 14 Ville Skyttä 2005-07-23 11:03:15 UTC
*** Bug 164046 has been marked as a duplicate of this bug. ***

Comment 15 Jens Petersen 2005-11-16 03:18:33 UTC
Created attachment 121105 [details]

This patch submitted by a RHEL customer is supposed to fix the problem
for 21.4 at least.

Comment 16 Ville Skyttä 2005-11-16 07:41:16 UTC
Thanks, but that's the same patch which was already discussed earlier here  
(see comments 12 and 13); it has been already applied in upstream 21.4.17 but 
should help with earlier 21.4.x versions. 
It appears to fix the lockups seen by some people, but still doesn't allow  
XEmacs to unmaximize after maximizing :( 
By the way, I had a chance to test the bleeding edge 21.5.x from CVS, and the 
problem persists there. 

Comment 17 Francois L'Archeveque 2006-01-04 15:43:23 UTC
The problem is present in "Red Hat Enterprise Linux WS release 4 (Nahant Update
2)" which has xemacs-21.4.15-10.EL.1.  Upgrading to xemacs-21.4.17-0.FC2 does
not help even though that version includes a maximization fix for MetaCity.

The kde bug 93155 relating to this was closed as "Invalid" so the bug is
believed to be caused by xemacs (http://bugs.kde.org/show_bug.cgi?id=93155).

The bug is present under KDE and GNOME but xemacs maximize/restore works ok with
Open MOTIF and Blackbox window managers (all running RHEL4 update 2).

Comment 18 Jonathan Abbey 2006-03-23 19:59:30 UTC
Still present in 21.4.19-3.fc5

Comment 19 Ville Skyttä 2006-05-02 15:44:07 UTC
Maximizing/minimizing appears to work for me on FC5, GNOME, all updates
installed, 21.4.19-4.fc5 (and 21.5.26-4 from devel rebuilt on FC5).

There's at least one glitch though: after maximizing the window, the text
content area is not immediately resized to cover all of the maximized window,
but it takes a few seconds.

Other experiences with latest FC5 updates installed?

Comment 20 Jens Petersen 2006-05-04 04:55:35 UTC
Oh, yes, works for me too.  It is funny how the text window takes some seconds
to update: perhaps that is why it was thought not to be working yet at all
until now?  But this is a big improvement and after maximising the first time
subsequent times seem to be instant.

Comment 21 Ville Skyttä 2006-05-07 20:33:59 UTC
More good news, upstream has posted a patch that fixes rest of the maximization
problems for me in GNOME and KDE.

The patch is currently available for XEmacs 21.5.x series only though, and is
applied in the just-queued 21.5.26-5.fc6 for FE devel:

Hopefully a similar fix will be available for the 21.4.x series soon too.

Comment 22 Christian Iseli 2007-01-19 07:20:52 UTC
This bug hasn't been updated in a long time and targets FE devel.
Could you please check that it still occurs with current FE devel and update
accordingly ?


Comment 23 Jonathan Abbey 2007-01-19 14:07:37 UTC
This bug has been fixed, and does not appear in the version of XEmacs that is on
the Fedora Extras repository for Fedora Core 6.

Comment 24 Matthew Saltzman 2007-01-19 14:29:23 UTC
I'll confirm that I haven't seen this in a while.  Currently using
xemacs-21.5.27-6.fc6 (latest production) and fully updated FC6 GNOME WM.

Comment 25 Ville Skyttä 2007-01-19 18:16:19 UTC
Thanks for the comments, however I'm pretty certain that 21.4.x series in FC5 is
still affected -> adjusting version accordingly.

Comment 26 Ville Skyttä 2007-07-02 17:57:07 UTC
FC5 is EOL, closing as CURRENTRELEASE.