Hide Forgot
+++ This bug was initially created as a clone of Bug #671088 +++ --- Additional comment from djasa on 2011-02-23 09:27:27 EST --- Setting back to ASSIGNED because I reproduced it again on gnome-panel-2.30.2-11.el6.x86_64. Gnome was configured by gnome-display-properties to only use external monitor if present. I did two test runs with my normal user configuration without any on-the-fly changes to monitor layout, once in 1600x900 and second time in 1920x1080. Note that position of dock on top panel and trash icon on bottom pannel changes with respect to other applets, a thing that should never happen without explicit user's action. --- Additional comment from djasa on 2011-03-04 11:06:50 EST --- Created attachment 482315 [details] reproducer on -12 --- Additional comment from djasa on 2011-03-04 11:08:09 EST --- Created attachment 482317 [details] screenshot of reproducer on -12 --- Additional comment from djasa on 2011-03-04 11:08:46 EST --- Created attachment 482318 [details] reproducer on -12 --- Additional comment from djasa on 2011-03-04 11:11:36 EST --- Created attachment 482320 [details] screenshot of reproducer on -12 Still reproducible on -12 the same way as on -11: set up gnome to use only external monitor when docked, log out, undock laptop, log in and see different applet order. --- Additional comment from rstrode on 2011-03-07 14:38:31 EST --- So I hammered on this pretty hard today. The bug mentioned in comment 24 is actually different than the one mentioned in comment 0, and it's even reproducible with the gnome-panel shipped originally in rhel6. To reproduce, just do something like while true; do pkill -f gnome-panel; sleep 1; done and watch the applets in the top panel along the corner occasionally switch places with each other. Since it's an independent issue, we need to track it separately in a new bug report. I'll clone this one. My theory at the moment is it's race between the individual applets loading. The way the panel gets them in place is it sets them all as "right stuck" and it puts one applet at pixel 0 from the right, one applet at pixel 1 from the right, one applet at pixel 2 from the right, etc. Each applet is more than one pixel wide though, so as soon as one is allocated, it will overlap the initials position of the others. I belive this means, they get pushed over, such that if an applet on the right gets loaded after an applet on the left it may end up shown to the left. It's just a theory and I'll need to investigate more on the other report. We're getting down to the wire for 6.1, though, so I think we may need punt fixing this for another time.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/