Bug 235781

Summary: enabling desktop effects makes panel drawers "sticky"
Product: [Fedora] Fedora Reporter: Michael Wiktowy <michael.wiktowy>
Component: compizAssignee: Kristian Høgsberg <krh>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 9CC: mcepl, valent.turkovic, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512120 (view as bug list) Environment:
Last Closed: 2009-07-14 17:08:44 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:
Attachments:
Description Flags
Original xorg.conf file created by anaconda and never edited
none
Xorg.0.log gzipped
none
Xorg.0.log after the xorg.conf file was removed and system rebooted gzipped
none
Local copy in more RH-friendly format
none
Xorg.0.log
none
Xorg.0.log with enabled desktop-effects (compiz) none

Description Michael Wiktowy 2007-04-10 05:36:18 UTC
Description of problem:
When Desktop Effects are enabled, drawer applets on the panel do not open
properly. They stick partially open and require multiple attempts to get them
open fully.

Version-Release number of selected component (if applicable):
compiz.i386 0.3.6-7.fc7 installed

How reproducible:
Frequent

Steps to Reproduce:
1. create a drawer applet and fill it with multiple application icons
2. enable desktop effects
3. try to open closed drawer applet
  
Actual results:
It will slide open part-way some of the time.

Expected results:
It should slide open always.

Comment 1 Valent Turkovic 2007-04-18 09:42:13 UTC
I have this issue also, even with the latest updates!


Comment 2 Valent Turkovic 2007-04-18 09:44:46 UTC
ps. this is a real annoying bug, and makes using gnome drawers almost unusable.

Comment 3 Matěj Cepl 2007-08-17 14:48:44 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.


Comment 4 Michael Wiktowy 2007-08-27 22:14:20 UTC
Created attachment 174681 [details]
Original xorg.conf file created by anaconda and never edited

Comment 5 Michael Wiktowy 2007-08-27 22:15:27 UTC
Created attachment 174701 [details]
Xorg.0.log gzipped

Comment 6 Michael Wiktowy 2007-08-27 22:16:34 UTC
Created attachment 174721 [details]
Xorg.0.log after the xorg.conf file was removed and system rebooted gzipped

Comment 7 Michael Wiktowy 2007-08-27 22:22:14 UTC
The attachments as requested.
My system is a fresh install of F7 that is up to date.
The problem still exists. I create a drawer applet and fill it with 4+ launchers
form the menu. The drawer opens slowly and not completely. I have moved it
around to different panels to see if that affects anything and now it has
stopped opening altogether ... even after a reboot. The rest of the 3D desktop
effects seem to work well on this video card (Radeon X800XL).

Comment 8 Matěj Cepl 2007-08-28 13:14:58 UTC
I have here just Radeon X600 but I really cannot reproduce this. I have added
drawer to my panel and four applets there and although opening wasn't immediate
(it took like a second on my dual-processor dual-core computer), but still I
think it was useful.

Handing this to developers and letting them do what they want.

Comment 9 Michael Wiktowy 2007-08-28 23:21:34 UTC
Just some more info to help narrow things down:
The characteristics of this bug have changed since I first saw it.
Before, the drawer stuck part way periodically.
Now it opens almost fully after a second or so delay but it still covers a small
part of the icon closest to the panel. It also doesn't open at all after a while.

My system is freshly installed from the F7LiveCD so there is no legacy desktop
config cruft lying around that could be causing this. I am using the video
drivers that came with the distro ... no third party binary ones. I just using
the basic compiz ... no beryl installed yet.

Comment 10 Valent Turkovic 2007-09-01 09:44:49 UTC
Yes the bug is still present.

I updated ranhide with latest patches and the bug is still present.

I removed and reinstalled: compiz, gnome-compiz-manager and gnome-compiz and
still the same issue happens.

Please look at it now.

Comment 11 Valent Turkovic 2007-09-01 09:56:03 UTC
check out youtube video of this bug:

http://www.youtube.com/watch?v=APTAu4ZRd60

Comment 12 Matěj Cepl 2007-09-03 10:38:11 UTC
Created attachment 185171 [details]
Local copy in more RH-friendly format

This is pretty good -- I think we've got much better idea, what's the problem.
Just one small problem -- you have discovered some problems with ffmpeg and
playing of SWF files without audio codec. So, I am rather attaching this as
OGG.

Comment 13 Valent Turkovic 2008-01-26 02:53:36 UTC
I still see this with Fedora 8 with latest updates.

Comment 14 Valent Turkovic 2008-01-27 17:04:26 UTC
also in rawhide

Comment 15 Valent Turkovic 2008-01-27 17:08:33 UTC
Created attachment 293080 [details]
Xorg.0.log

I have no xorg.conf file
I use intel video chip on HP Pavillion laptop:

from lspci:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller (rev 03)

Comment 16 Valent Turkovic 2008-01-27 17:12:36 UTC
ups, last log was with desktop-effects (compiz) disabled. I'll enable them and
reattach the log.

Comment 17 Valent Turkovic 2008-01-27 17:14:08 UTC
Created attachment 293081 [details]
Xorg.0.log with enabled desktop-effects (compiz)

Comment 18 Valent Turkovic 2008-02-02 17:06:37 UTC
I got this feedback from Danny Baumann <dannybaumann> on compiz mailing list:

I had a look into this and it looks like the panel drawer doesn't
properly respond to the _NET_WM_SYNC_REQUEST protocol. Compiz sends out
a sync request, but gets no response from the drawer window. After 1
second, the Compiz internal sync response wait timer times out (and the
resize is carried out), that's the delay you're seeing.
I didn't have the time yet to analyze in-depth why the drawer window is
different from other GTK windows, but maybe someone else has an idea
based on this information.

Kristian and Matej does that give you some ideas?

Comment 19 Valent Turkovic 2008-02-04 21:06:52 UTC
compiz devels recognised this as a gnome bug and posted it upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=514298

Comment 20 Valent Turkovic 2008-02-06 15:33:47 UTC
from:
http://bugzilla.gnome.org/show_bug.cgi?id=514298

Comment #2 from wheerdam    (points: 1)
2008-02-06 04:22 UTC [reply]

I can confirm this on Fedora 8 with Compiz running (Gnome 2.20.2). I use nvidia
binary driver.


Comment 21 Valent Turkovic 2008-02-06 15:35:26 UTC
this should be changed to gnome bug, not compiz

Comment 22 Matěj Cepl 2008-02-06 16:27:03 UTC
(In reply to comment #20)
> I can confirm this on Fedora 8 with Compiz running (Gnome 2.20.2). I use nvidia
> binary driver.

Sorry, but then such information is just confusing. Binary-only nvidia drvers
behave just so differently, that I would love to keep them outside of this
conversation, please. If you cannot reproduce the bug with open source drivers,
just say nothing please. I am aware that this probably is not driver-specific
bug, but it is enough confusing already.

Comment 23 Bug Zapper 2008-05-14 02:45:30 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 24 Bug Zapper 2009-06-09 22:32:26 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 25 Valent Turkovic 2009-06-28 09:56:40 UTC
This is still a bug on Fedora 11 with all the latest patches

Comment 26 Valent Turkovic 2009-06-28 10:32:22 UTC
You can see for yourself:
http://www.youtube.com/watch?v=M7mj4uiS9vY

Comment 27 Bug Zapper 2009-07-14 17:08:44 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

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