After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 509922 - window taskbar repaints improperly when minimized window ghost crosses a hightlighed window entry
window taskbar repaints improperly when minimized window ghost crosses a high...
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: window list
unspecified
Other All
: Normal minor
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-16 15:58 UTC by Mark Baldridge
Modified: 2020-11-06 20:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Mark Baldridge 2008-01-16 15:58:35 UTC
Please describe the problem:
The taskbar had two windows, Sound Juicer on the left and Firefox to the right.  Sound Juicer had finished extracting tracks and had put up a window underneath the Firefox window, just sticking out on the right.  I clicked on the visible area to bring it to the top, to see if it had completed successfully, or had some issue.  The window just vanished.  Sound Juicer still wanted attention, since its taskbar entry was highlighted blue.  So I minimized the Firefox window by clicking on its taskbar entry.  As it minimized, it produced the shrinking window ghost to the Firefox taskbar entry.  That overwrote the blue highlight of the Sound Juicer taskbar entry.  
The problem is that the Sound Juicer taskbar entry repainted the backgound with the normal gray color rather than the blue attention color.  This produced a taskbar entry with two background colors, blue on the lower left and gray on the upper right, with a diagonal, slightly staircase, division between the two background colors.
An attempt to take a screenshot caused the Sound Juicer tab to repaint in its proper attention-blue when the "take screenshot" button was clicked, just prior to the actual screenshot.
Since the text on the Sound Juicer tab repainted through the background color difference, it must be seeing the repaint event; it is just using the wrong background color for the part that gets uncovered as the shrinking window ghost passes. 

Steps to reproduce:
1. Open Sound Juicer and start extracting.
2. While Sound Juicer is running open a firefox window over it, positioned so the Sound Juicer "all done" popup window will appear, mostly under, the firefox window
3. Click on the visible portion of the popup window.  I think you need to click on the window close X in the upper right corner to leave the Sound Juicer window in the window list in the hightlight state.  Or maybe at this point, just minimize the firefox window by clicking on its window entry in the task bar.



Actual results:
Sound Juicer window entry in the window list will have two gackground colors.

Expected results:
The whole background of the Sound Juicer window entry in the window list should repaint all "I want attention"-blue.

Does this happen every time?
Yes.  I can only get the Sound Juicer to respond this way if it is behind the Firefox window when it completes and X out the popup window.  The window list in the taskbar stays blue.  If Sound Juicer is the only window when the popup window is X-ed out, the window list shows the window in its normal state of gray.

Other information:
Part of this issue may be that X-ing out the Sound Juicer extraction-complete popup window is not properly handling the window-close event.  Possibly when the window list entry gets interrogated, it say, 'paint attention' and paints a blue background.  When the window ghost close box runs across the window list task bar entry, something responds with 'paint normal' so the repainted area gets a gray color.
Comment 1 Arand 2010-03-28 19:17:11 UTC
Bug reported downstream:
http://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/549919
(screenshot & video attached for clarity)

happens with metacity but not with compiz.
Comment 2 Arand 2010-03-28 21:24:11 UTC
And I can also confirm that this is present on the latest versions of gnome-panel and metacity in Gnome dev kit (virtualbox instance)
Comment 3 André Klapper 2020-11-06 20:21:50 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.