GNOME Bugzilla – Bug 513347
gnome panel freeze when opening more than 7 windows on a right panel.
Last modified: 2014-05-23 12:59:20 UTC
This bug can always be reproduced and happen in very precise circumstances. When using the "windows list" applet (installed by default) on a gnome panel of at least 30 pixels placed in the right of the screen, it's impossible to open more than 7 windows without freezing completely Gnome-panel and needed to restart Gnome. Since gnome-panel freeze but does not crash, I can't create a backtrace. This bug is due to the fact that when the gnome-panel is more than 30 pixels, icons are shown for each windows in the panel. When Gnome has 7 windows, icons are stretched and there's no place for another window. At that moment, if 8th window is open, the "windows list" panel panic and gnome-panel freeze. How to reproduce that bug on ubuntu : 1. Right clic on the default ubuntu bottom panel and click on "properties" 2. Change "Bottom" to "Right" and increase the size to 30 pixels or more ( icons must appear in the windows list in the gnome-panel when the panel is in the right of the screen ) 3. Once the panel is at right, open 8 windows. Result : Gnome panel is now completely freeze, except the notification area. Tested on gutsy and hardy, gnome-panel 1:2.20.1-0ubuntu1 and 1:2.21.90-0ubuntu1 Launchpad bug : https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/187540
This isn't reproducible with gnome-panel trunk, maybe an Ubuntu specific bug.
I found that this bug also apply to debian and that even when re-packaging the ubuntu gnome-panel package without the debian/patches folder, the bug is still there. Are you sure that you can't reproduce the bug with the trunk? Confirmed for Debian Sid, gnome-panel 2.20.3-1 Does NOT happen with : Debian Lenny, gnome-panel 2.14.3-6
Confirmed on OpenSuse too, gnome-panel 2.20.0
This has connection with #86382. This bug is reproducible in GNOME 2.21.90. See screencast: http://bugzilla.gnome.org/show_bug.cgi?id=86382#c58 It is not a Ubuntu specific bug, it can be reproduced also in OpenSUSE 10.3 with GNOME 2.20.
also confirming this bug for Debian Sid.
Can still be reproduced with gnome-panel 2.22.0 A video that shows how to reproduce the bug : http://www.youtube.com/watch?v=dhCbnq08roA
Not freezing on my Fedora 9, but the app list keeps "blinking" as if it was constantly recalculating and resizing the button width.
(In reply to comment #7) > Not freezing on my Fedora 9, but the app list keeps "blinking" as if it was > constantly recalculating and resizing the button width. > I've reported it to Red Hat bugzilla as #438959. The screencast of the Fedora defect: http://www.youtube.com/watch?v=v4GvNbjNlK8
Why is this bug still "unconfirmed"? There have been reports for OpenSuse, Ubuntu and Debian. This should be sufficient proof that there /is/ a problem...
(In reply to comment #9) > Why is this bug still "unconfirmed"? There have been reports for OpenSuse, > Ubuntu and Debian. This should be sufficient proof that there /is/ a problem... Because I nearly don't make a difference between UNCONFIRMED and NEW...
Created attachment 113638 [details] [review] A patch fixing this bug. Uses size hints only for width, not height. It was an obvious bug as the size hints are computed for *width*.
Created attachment 113639 [details] [review] Improves appearance for vertical window list. The height of the window list applet is computed according to the number of rows. This saves space when only couple of windows is opened.
The recent patches are applicable to today's trunk of gnome-panel and libwnck.
I tested the gnome-panel patch under intrepid (gnome-panel 1:2.22.2-0ubuntu2) and the patches fixes the problem. I was able to open 60 gnome-terminal windows with no problem. However, a side effect is that a single window takes the whole bar and it is not possible to right clic to set the bar to bottom instead of left/right without removing window list applet temporarily.
Strangely, I can't reproduce what I mentioned before, even without libwnck patch applied. Anyway, works perfectly with libwnck and gnome-panel patches here, thanks for this great work!
Unfortunately, the first patch breaks the meaning of size hints. The size hints are valid in a vertical panel too. The problem is that the window list doesn't correctly generate them. I'm not sure the second patch is useful without the first one... The fix really is to finish my patches in bug #86382.
(In reply to comment #16) > Unfortunately, the first patch breaks the meaning of size hints. The size hints > are valid in a vertical panel too. The problem is that the window list doesn't > correctly generate them. I'm not sure the second patch is useful without the > first one... > > The fix really is to finish my patches in bug #86382. > What are the chances for this to happen any time soon? I have meanwhile written a little script for myself, which kills the panel and restarts it, including everything that does not properly restart itself, in case that I again have opened one too many window. However, this is certainly not an option for the non-technical users at whom GNOME always claims to be targeted.
(In reply to comment #17) > (In reply to comment #16) > > Unfortunately, the first patch breaks the meaning of size hints. The size hints > > are valid in a vertical panel too. The problem is that the window list doesn't > > correctly generate them. I'm not sure the second patch is useful without the > > first one... > > > > The fix really is to finish my patches in bug #86382. > > > > What are the chances for this to happen any time soon? I'll try to get this ready for 2.24, but I might not have time...
Vincent, You said this well over a year ago about 2.20 here: http://bugzilla.gnome.org/show_bug.cgi?id=86382#c25 :) That bug was first reported in 2002...
>Vincent, >You said this well over a year ago about 2.20 here: >http://bugzilla.gnome.org/show_bug.cgi?id=86382#c25 >:) >That bug was first reported in 2002... I am using gnome 2.24 now, but the problem still exits. Vincent is always right when he says "I'll try to get this ready when xxx, but I might not have time...". hehe Sorry for my joke if my English is bad. :)
Your joke came through good enough man, made me laugh out loud in my cubicle :) On a more serious note, though, this sucks... The maintainer has pretty much let this go for over 6 years now because he doesn't have a widescreen monitor, which have become so popular nowdays that I hardly see any 4:3 screens at the major electronics stores around here...
Thanks prl77. here is an update to this bug: I installed Ubuntu alpha 5, and the panel freezed when there were more than 10 or more windows, not 8. I did not remember it precisely. And after a certain Ubuntu updade, it freezed at 8 windows again. Now, I have an Ubuntu standard release now, and it freezs at 10 window again. Hope the above info could help you. ;-)
I am the author of the above comment. I should have mean I installed Ubuntu 8.10 alpha5 and standard release. ;-) I really hope it could be fixed soon. ;-)
Bug seems to still exist, which forces me to kill the gnome-panel a few times a day. I am sorry gnome-panel, its nothing personal.
Hi Emie Taner, here is a patch to this problem. it is easy to use, it tested it on ubuntu 8.04 and 8.10 and it worked well. Hope it is helpful to you. http://ubuntuforums.org/showthread.php?t=968901
Created attachment 130484 [details] if the 8th window appear ALT+F2 and upper areas don't work until "killall gnome-panel" dpkg -s gnome-panel ... Maintainer: Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com> Architecture: i386 Version: 1:2.25.92-0ubuntu1 ...
Created attachment 130664 [details] gnome 2.24.1 This bug is not Ubuntu specific, I recreate under Debian/Lenny and OpenSUSE 11.1 when the panel that holds the task switcher is vertical (left or right side) and the width between 30-47pixels the 8th individual button (when you grouping;please not count the panel properties) block the task switcher and most part of the gnome-panel or block the system a:open 8 individual button in a same workspace b:set panel size to 30-47 c:set to vertical the bug shows when a+b+c in same time (any order you make)
here is a bad news. this problem exists in ubuntu9.04(still in alpha stage) with gnome 2.26 also. The God cried, "I will not see this bug fixed before I die!"
also confirming that GNOME 2.26 is still affected. On Ubuntu Jaunty Beta 1 this bug is still reproducible as on any other GNOME installation.
*** Bug 511994 has been marked as a duplicate of this bug. ***
Are there news about this bug ? we are approccing two years !!!!
Created attachment 150590 [details] [review] Patch Add an orientation to WnckTasklist Pass the orientation from the panel Test the orientation when computing the layout.
I was hit by this problem and created a patch which I've attached here. My perception of the root cause is that the WnckTasklist doesn't know about the preferred orientation of the panel, so I teached it. Per design, it doesn't try to put the names vertically, I feel that just the icons are enough to find which window I want (By the way, instead of [] ... I think that simply the icon would be better). It doesn't go with a two columns layout even in cases where it would be better. I've investigated the issue. I will if it comes to annoy me, but I don't use so many windows that it is an issue in my configuration, so don't hold your breath. Yours, -- Jean-Marc
Created attachment 150632 [details] [review] Combination of a fix for the hang and a better layout when heavily constrained Well, my wife configuration was affected. Here is a variant of the previous patch which touch more deeply at the layout algorithm. When layouting the tasklist (as opposed to when requesting a size), it will add to the minor direction in order to keep the buttons squarish. For a vertical layout, this mean that if your width is wide enough, it will start as a one column with the start of the name, but add other columns in order to make the buttons more or less square (and even a little more aggressively if the mini-icons stay visible). To the maintainers, I didn't mark my previous patch as obsolete as that one was a little safer: it didn't modify the behavior of horizontal lists, making it more suitable as a bug fix while this one is more an enhancement.
This patch triggers another bug here: the first window to be displayed doesn’t get its title printed in the window list; just “…”. Only when a second window appears, the two of them are displayed correctly. This gets worse when fonts are configured to look bigger. In this case, the panel process enters an infinite loop of computation of the size of the applet.
Whoops, wrong bug. Ignore my previous comment.
Just so that there is no confusion: comment#35 was about the patch in bug#86382, which causes this serious regression. Jean-Luc’s patch is more complex but much less intrusive, since it implies zero code change for horizontal panels. It doesn’t, of course, cause this behavior.
Hi, bug still exists on my gnome-panel-2.28, opensuse. It would be super great if this bug would soon disapear, because it is really lowering usability (widescreens are standard nowadays, a bar on top/button just makes no sense in widescreen). It is actually my personal #1 bug that could make me replace gnome by something else if it doesnt go away. Pretty please?
Created attachment 183951 [details] [review] Updated patch for libwnck 2.91.91
Created attachment 183952 [details] [review] Updated patch for gnome-panel 2.91.91 The changes are still applicable to 2.91. I don’t know whether they are still relevant since you can’t manually configure the panel, though.
(In reply to comment #40) > I don’t know whether they are still relevant since you can’t manually configure > the panel, though. Err, that's wrong, you still can. It's documented in NEWS (use the same modifier as the one defined for metacity when right-clicking).
(In reply to comment #41) > Err, that's wrong, you still can. It's documented in NEWS (use the same > modifier as the one defined for metacity when right-clicking). It’s probably a separate bug, but this doesn’t work here. Does it need a more recent metacity version?
It shouldn't need any recent metacity version. I'm aware of an issue where, if you don't have the metacity schemas installed, you're stuck, though. Hrm. Would you have some time to take a look at this? Grepping for panel_bindings_get_mouse_button_modifier_keymask() gets you all the relevant code. For the panels, it's panel_button_press_event() in panel.c.
Fixed in master - https://git.gnome.org/browse/gnome-panel/commit/?id=69e1e261be8226eec1cf3cbec77b88500bb64e57 In commit message I wrote that patch comes from debian, bet seems that original author of patch is Jean-Marc Bourguet and/or Josselin Mouette. libwnck patch has been merged almost year ago - https://git.gnome.org/browse/libwnck/commit/?id=39cb86fe041ad24daa0367a31e9e7f4f876fc521