Unfortunately I haven't received any feedback from upstream about this.

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?

XEmacs upstream are aware of the issue.

Still occurs with 21.4.15.

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

Regular GNU Emacs used to rely on the WM implementing a short-circuit,
i.e.:

  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.

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
loop.

I believe this was recently fixed in the 21.5 beta series.,
but didn't get round to backporting the fix...

Can we expect some fix in the near future?

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.

No, it is not fixed yet in xemacs-21.4.17-3 afaict.

http://list-archive.xemacs.org/xemacs-patches/200412/msg00077.html

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

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).

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

Created attachment 121105 [details]
xemacs-21.4.1.17-lockupfix.patch

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

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. 

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).

Still present in 21.4.19-3.fc5

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?

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.

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:
http://cvs.fedora.redhat.com/viewcvs/*checkout*/devel/xemacs/xemacs-21.5.26-maximize.patch?root=extras

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

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 ?

Thanks.

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.

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.

Thanks for the comments, however I'm pretty certain that 21.4.x series in FC5 is
still affected -> adjusting version accordingly.

FC5 is EOL, closing as CURRENTRELEASE.
https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00001.html