|Summary:||maximizing causes xemacs to freeze up|
|Product:||[Fedora] Fedora||Reporter:||Yaron Minsky <yminsky>|
|Component:||xemacs||Assignee:||Ville Skyttä <ville.skytta>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||5||CC:||Christian.Iseli, disnel, fla_2, hp, jonabbey, maayant, mjs, petersen, sylvain.ferrand|
|Fixed In Version:||21.5.28||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-07-02 17:57:07 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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) Gecko/20031114 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): xemacs-21.4.14-3 How reproducible: Always 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: http://list-archive.xemacs.org/xemacs-beta/200311/msg00089.html
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, 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.
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 loop.
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
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.
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] xemacs-188.8.131.52-lockupfix.patch 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: 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.
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 ? Thanks.
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. https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00001.html