Bug 75225
| Summary: | Panel Notification Area ends up a single pixel wide | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Xu Hao Qing <xhq> |
| Component: | gnome-panel | Assignee: | Mark McLoughlin <markmc> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | amb82, bugzilla, chris.ricker, dch, fmonkey, fred.new2911, gczarcinski, gerry, leonard-rh-bugzilla, menthos, mike, mitr, nmarsh1, otaylor, pzbowen+rhbeta, redhat-mail, rick, thobart, twaugh, wtogami |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-02-26 14:56:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 79579, 100644, 101482, 104701 | ||
|
Description
Xu Hao Qing
2002-10-05 17:18:48 UTC
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. 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. 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-2.2.0.1-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 something else? 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 other icons/applets. 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 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 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 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. 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. 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 normally. 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. *** ping.. 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 NEXTRELEASE? 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 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". |