Red Hat Bugzilla – Bug 75225
Panel Notification Area ends up a single pixel wide
Last modified: 2007-04-18 12:47:13 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809
Description of problem:
Under zh_CN.GB18030 locale, Panal Notification Area is too small(only about one
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Chose Simplified Chinese locale and login
2.By default, there will be a "Red Hat Network Warnning Notification
Tool(Translated from Chinese)" in the Panal Notification Area.
Actual Results: The "Red Hat Network Warnning Notification Tool(Translated from
Chinese)"'s notification icon can be hardly seen. It's only about one mm wide.
Expected Results: It should be as wide as in en_US locale.
Really strange problem ;)
I've seen this in other locales as well, I think it's a general problem.
I can reproduce this error with en_US.UTF-8 locale set.
1. Reboot the machine, choose en_US.UTF-8 locale and login gnome2, the update
notification icon works with no problem.
2. Logout, choose zh_CN.GB18080 locale and login gnome2, the update notification
icon can hardly be seen.
1. Reboot the machine, choose zh_CN.GB18080 locale and login gnome2, the update
notification icon works with no problem.
2. Logout, choose en_US.UTF-8 locale and login gnome2, the update notification
icon can hardly be seen.
Conclusion: It will have problem if you are in such a gnome2 session -- it has a
different locale than the one of the first gnome2 session after last reboot.
I haven't seen this recently, it may be fixed upstream, but
if not we should look into it. It seems like it may be a plug/socket issue as
basically the size request/allocation doesn't end up right.
*** Bug 79577 has been marked as a duplicate of this bug. ***
*** Bug 84569 has been marked as a duplicate of this bug. ***
I've seen this in the last 48 hours, in either gnome-panel-22.214.171.124-5 or -4
Please understand that on my machine the gnome bar is now more than one screen wide and
all programs minimized are off the screen along with the notification area.
why is my bug here?????
the red spot is gone,and is now a thin white line one mm TALL, one cm WIDE!!!!
click on the "notification area" menu link, and you get a replica beside it, and
can't get rid of either one!
what happened to my bug report???
Hi, I can still see this occasionally in Red Hat 9.
TALL dammit! 1 pixel TALL. git your head out of your butt and pay attention.
dfowensby: it's almost 100% certain that a 1-pixel high applet
is a slight variant of the same bug as a 1-pixel tall applet.
Please calm down.
Confirmed on RHL9 after a fresh install. Seen following the firstboot wizard.
Install logs available upon request.
*** Bug 87925 has been marked as a duplicate of this bug. ***
*** Bug 73762 has been marked as a duplicate of this bug. ***
i hear this is still happening in the RedHat "9.0" upgrade. why not go with
Seems related to this bug #76901 too.
*** Bug 76901 has been marked as a duplicate of this bug. ***
What would be useful here would be to figure out a reproducable
way to get this to happen. I've seen it a total of one time, and
never have been able to reproduce it when I've wanted to debug it.
Try removing the Notification area applet, then readding it to see if that does
it. You may have to test with and without killing off rhn-applet before doing
it and during.
Removing/readding the notification applet works fine for me.
(OK, rhn-applet-gui seems to be buggy in that it exits when
you remove the notification area, instead of waiting around
for a new notification area to be created, but that's not
related to this in any way I can see.)
The one time I saw this was after a new RH9 install. The interesting part about
it is that while the RHN icon was only 1px wide, the keys icon in the same
notification area was displayed correctly.
This made me think that maybe the problem was less with the notification area
and more with the RHN icon/applet.
I believe though, that when you remove the notification area, the other icons
stay put. So they wouldn't exactly be using the same thing. from what I see.
No, you missed what I was saying.
After a default install the RHN icon was present in the notification area and
was displayed as a single pixel vertical line. I chose to ignore it and move on
with the config setup.
I launched 'neat' from the System Settings menu which prompts for a root passwd.
After authenticating a 'keys icons' appearded in the notification area next to
the RHN icon which was still showing up as a single pixel vertical line. The
keys icon was displaying normally.
At this point, in the same notificaiton area, one icon was displaying
incorrectly while another icons was displaying correctly.
This sequence of events has nothing to do with removing the notificaiton area or
I can reproduce this problem on both Red Hat Linux 8.0 and 9 official releases
for x86, and also on rawhide AMD64 bits.
Could one or more people:
- Describe an exact sequence of steps that results in the problem
with a brand new user
- Describe the hardware that they are doing this on.
The reason I ask for the hardware is that I think this is some
sort of race condition, and I have no idea if my test machines
are too fast or too slow.
On P3-series Celeron 500s with 256 megs RAM, I
* install RHL 9 via kickstart from NFS
* log in as the new user created in the %post of kickstart
* am immediately greeted with a "skinny" rhn-applet
On my dual P2-366 256 megs RAM at home, I got the "skinny" rhn-applet out of the
box on RHL 8.0, but so far am non-skinny on RHL 9
I take that back. My dual PII at home was proudly displaying the 1-pixel-wide
rhn-applet after I had to reboot this morning....
This happens to me every other time I login and the first time I log in to a
Intel Pentium III 450 MHz processor on an Intel 440BX motherboard latest A10 BIOS
384 MB SDRAM
Integrated 4MB ATI Rage graphics (this is a Dell OptiPlex G1)
CD-ROM and HDD on IDE (separate channels)
3com 3C905b NIC
Adaptec 39160 SCSI with attached tape drive
PS/2 keyboard with generic wheel mouse
I'm getting this problem intermittently on all of my computers, ranging from a
Pentium 75 with 40 MB to a Pentium 4 1.7G with 256 MB. All of the gnome-panels
are set at "X Small". Desktops are set at 800 x 600 (the P75) and 1024 x 768.
Just now, I killed the rhn-applet-gui and restarted it, and the problem went
away (on the P4 1.7G system). It came back once after rebooting, but after
killing it again and rebooting, I haven't been able to make it recur. (But I'm
sure it will come back.)
The problem still happens for me in Red Hat Linux 9, however I'm no longer
using the panel applet, so not interested in this bug anymore.
I have hit this problem while adding xembed system tray support to Wine.
As my code currently stands, the first attempt to dock in a session will fail
(the window attempts to dock, is swallowed but given a 1px allocation then spat
out agan). Simply running the same program again will succeed. Therefore, I'm
not sure if it's my code that's buggy or the panel applets, but I suspect the
This is nearly 100% reproducable with my current code. I will hopefully get time
at work to investigate this issue soon at work. Otherwise, you may be able to
reproduce it by installing Wine, applying my system tray patches, and then
trying it with a simple test application which I can supply on request.
Unfortunately, the likelyhood that we'll (or at least I'll) have a chance
to try out a test case that involves Wine + custom patches any time
soon is quite low. Something standalone wouldbe a lot easier to
I suspect the "spat out again" problem is a bug in your code, since it
isn't an issue with any of the bug reports we've been receiving for
other notiification icons.
I tried fixing this problem by removing the notification area from the panel and
replacing it. In the process I created a new variant, where the RHN alert
applet doesn't display at all, and the keys icon is 1 pixel high (Bug 101482)
Oops. I meant to say the keys are 1 pixel WIDE. Normal height. And I'm also
using RH 9.
This problem also occured for me on Fedora test2. It only happened for root.
After I created a new user and logged in as that user, the applet displayed
The abnormal one was about one pixel wide and normal height.
Also happened to me on Fedora Test 2 as normal user. Logging out/back in
restores the applet sometimes.
*** Bug 105887 has been marked as a duplicate of this bug. ***
This bug is easy to reproduce. Simply go to the Sessions control application
and change the priority of the rhn-applet to anything less than the notification
area applet and you will see it happen. To solve this problem you can also go
into the Session control application and set the priority of the notification
area applet to anything less than the rhn applet (and other applets that need
the notification area applet as well). The race condition is whether or not the
rhn-applet tries to get space on the notification area before the notification
area applet is up and running or not. Changing the default session start
priority of the user notification area applet to something less than the typical
startup priority of apps that use the notification area would solve this problem
once and for all.
*** Bug 106278 has been marked as a duplicate of this bug. ***
*** Bug 101482 has been marked as a duplicate of this bug. ***
*** Bug 104603 has been marked as a duplicate of this bug. ***
Has this finally been resolved yet? I know I haven't really seen it
happen on a FC1 + updates yet.
Is this an issue with FC 1 or RHEL 3? If not, maybe close this one
I know I haven't seen it happen since Fedora 2 Test 1 and rawhide
updates. So far so good.
Your comment suggest you did see this in FC 1? Did you? Or anyone else?
I might have seen this when I originally installed FC1. But it is
working correclty now with rhn-applet-2.1.4-3.i386.rpm on FC1.
In that case this is not a gnome-panel issue. The component can thus
be changed to rhn-applet. And since the update solved the issue it can
be closed ERRATA as well.
Just FYI, bug 106278 tells that this is fixed from rhn-applet >=
2.0.12 (which means it was already fixed in FC 1).
See bug 106985 for the "patches".