Bug 75225 - Panel Notification Area ends up a single pixel wide
Panel Notification Area ends up a single pixel wide
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gnome-panel (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mark McLoughlin
: Triaged
: 73762 76901 79577 84569 87925 101482 104603 105887 106278 (view as bug list)
Depends On:
Blocks: 79579 CambridgeTarget 101482 104701
  Show dependency treegraph
 
Reported: 2002-10-05 13:18 EDT by Xu Hao Qing
Modified: 2007-04-18 12:47 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-26 09:56:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xu Hao Qing 2002-10-05 13:18:48 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
mm wide).

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


How reproducible:
Always

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

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.

Additional info:

Really strange problem ;)
Comment 1 Havoc Pennington 2002-10-05 13:54:51 EDT
I've seen this in other locales as well, I think it's a general problem.
Comment 2 Henrik Brix Andersen 2002-10-06 14:55:36 EDT
I can reproduce this error with en_US.UTF-8 locale set.
Comment 3 Xu Hao Qing 2002-10-07 04:14:55 EDT
More info:

A: 
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.

B: 
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.
Comment 4 Havoc Pennington 2003-01-07 23:09:25 EST
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.
Comment 5 Bill Nottingham 2003-02-11 00:04:50 EST
*** Bug 79577 has been marked as a duplicate of this bug. ***
Comment 6 Peter Bowen 2003-02-18 20:32:08 EST
*** Bug 84569 has been marked as a duplicate of this bug. ***
Comment 7 Peter Bowen 2003-02-18 20:33:57 EST
I've seen this in the last 48 hours, in either gnome-panel-2.2.0.1-5 or -4
Comment 8 Terry Hobart 2003-02-18 20:43:42 EST
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.
Comment 9 dfowensby 2003-02-19 17:45:49 EST
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???
Comment 10 Xu Hao Qing 2003-04-05 08:42:08 EST
Hi, I can still see this occasionally in Red Hat 9.
Comment 11 dfowensby 2003-04-05 14:01:35 EST
TALL dammit! 1 pixel TALL. git your head out of your butt and pay attention.
Comment 12 Owen Taylor 2003-04-05 23:22:19 EST
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.
Comment 13 Scott Russell 2003-04-06 13:05:05 EDT
Confirmed on RHL9 after a fresh install. Seen following the firstboot wizard.
Install logs available upon request.
Comment 14 Daniel Veillard 2003-04-07 11:33:30 EDT
*** Bug 87925 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Veillard 2003-04-07 11:35:08 EDT
*** Bug 73762 has been marked as a duplicate of this bug. ***
Comment 16 dfowensby 2003-04-08 10:33:05 EDT
i hear this is still happening in the RedHat "9.0" upgrade. why not go with
something else? 
Comment 17 Mike Chambers 2003-04-23 08:32:37 EDT
Seems related to this bug #76901 too.
Comment 18 Owen Taylor 2003-04-23 09:52:18 EDT
*** Bug 76901 has been marked as a duplicate of this bug. ***
Comment 19 Owen Taylor 2003-04-23 10:04:40 EDT
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.
Comment 20 Mike Chambers 2003-04-23 10:08:34 EDT
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.
Comment 21 Owen Taylor 2003-04-23 10:26:56 EDT
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.)
Comment 22 Scott Russell 2003-04-23 10:37:18 EDT
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.
Comment 23 Mike Chambers 2003-04-23 10:41:29 EDT
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.
Comment 24 Scott Russell 2003-04-23 10:56:45 EDT
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
other icons/applets.
Comment 25 Mike A. Harris 2003-04-23 19:32:04 EDT
I can reproduce this problem on both Red Hat Linux 8.0 and 9 official releases
for x86, and also on rawhide AMD64 bits.
Comment 26 Owen Taylor 2003-04-24 12:20:28 EDT
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.
Comment 27 Chris Ricker 2003-04-24 12:26:21 EDT
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
Comment 28 Chris Ricker 2003-04-26 09:41:06 EDT
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....
Comment 29 Dustin Cook 2003-05-02 10:48:46 EDT
This happens to me every other time I login and the first time I log in to a
machine.

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)
Floppy
Crystal sound
no modem
RealTek NIC
3com 3C905b NIC
Adaptec 39160 SCSI with attached tape drive
PS/2 keyboard with generic wheel mouse
Comment 30 Fred New 2003-06-07 16:56:56 EDT
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.)
Comment 31 Mike A. Harris 2003-06-09 16:45:41 EDT
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.
Comment 32 Mike Hearn 2003-06-17 17:13:53 EDT
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
applets.

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.
Comment 33 Owen Taylor 2003-06-22 22:04:22 EDT
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
deal with.

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.
Comment 34 ab 2003-08-01 14:20:56 EDT
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)
Comment 35 ab 2003-08-01 14:24:23 EDT
Oops.  I meant to say the keys are 1 pixel WIDE.  Normal height.  And I'm also
using RH 9.
Comment 36 Gene Czarcinski 2003-09-26 08:48:08 EDT
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
normally.

The abnormal one was about one pixel wide and normal height.
Comment 37 Gerry Tool 2003-09-26 09:07:49 EDT
Also happened to me on Fedora Test 2 as normal user.  Logging out/back in
restores the applet sometimes.
Comment 39 Daniel Veillard 2003-09-29 04:55:55 EDT
*** Bug 105887 has been marked as a duplicate of this bug. ***
Comment 40 Doug Ledford 2003-09-29 17:08:57 EDT
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.
Comment 41 Daniel Veillard 2003-10-04 15:46:34 EDT
*** Bug 106278 has been marked as a duplicate of this bug. ***
Comment 42 Alexander Larsson 2003-10-06 10:44:19 EDT
*** Bug 101482 has been marked as a duplicate of this bug. ***
Comment 43 Daniel Veillard 2003-10-23 10:08:45 EDT
*** Bug 104603 has been marked as a duplicate of this bug. ***
Comment 44 Mike Chambers 2004-01-29 08:41:52 EST
ping..

Has this finally been resolved yet?  I know I haven't really seen it
happen on a FC1 + updates yet.
Comment 45 Leonard den Ottolander 2004-02-26 07:24:09 EST
Is this an issue with FC 1 or RHEL 3? If not, maybe close this one
NEXTRELEASE?
Comment 46 Mike Chambers 2004-02-26 08:03:07 EST
I know I haven't seen it happen since Fedora 2 Test 1 and rawhide
updates.  So far so good.

gnome-panel-2.5.3.1-6
rhn-applet-2.1.7-1.1
Comment 47 Leonard den Ottolander 2004-02-26 08:22:05 EST
Your comment suggest you did see this in FC 1? Did you? Or anyone else?

Comment 48 Fred New 2004-02-26 08:42:17 EST
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.
Comment 49 Leonard den Ottolander 2004-02-26 09:34:43 EST
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.
Comment 50 Miloslav Trmac 2004-02-26 09:56:51 EST
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".

Note You need to log in before you can comment on or make changes to this bug.