Bug 682858

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