Bug 607021

Summary: Stacking confusion for logout dialog
Product: [Fedora] Fedora Reporter: Owen Taylor <otaylor>
Component: compizAssignee: Adel Gadllah <adel.gadllah>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: adel.gadllah, dchen, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 467174 Environment:
Last Closed: 2011-06-01 18:56:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 467174    
Bug Blocks:    

Description Owen Taylor 2010-06-23 00:15:36 UTC
+++ This bug was initially created as a clone of Bug #467174 +++

Description of problem:
After select new im and click "logout", the logout/reboot/shutdown menu does not display if compiz and beryl is running.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install compiz or beryl if not presented.
2. Install at least two IMs, such as gcin and SCIM.
3. run either compiz or beryl 
   a. for compiz: by  system-> preference -> desktop effect
   b. for beryl: run beryl-manager
4. run im-chooser, select a the non-default IM to enable the logout button.
5. Click on logout
Actual results:
The logout/reboot/shutdown dialog exists but not displayed. Pressing [Enter] still gets to the default action "logout".

Expected results:
The logout/reboot/shutdown should display.

Additional info:
devilspie cannot detect the logout/reboot/shutdown dialog when it appear on the screen, but other dialogs, and dialogs from other applications can be detected by devilspie.

--- Additional comment from tagoh@redhat.com on 2008-10-16 22:46:24 EDT ---

im-chooser just uses libgnomeui's feature. unable to display GTK_WINDOW_POPUP dialog is a bug in compiz/beryl.

--- Additional comment from dchen@redhat.com on 2008-10-17 02:30:04 EDT ---

Mmm, it seems like the dialog is derived by gnome_client_request_save(). Shall we deem this bug is from either libgnomeui or compiz?

--- Additional comment from mcepl@redhat.com on 2008-11-11 09:09:07 EST ---

Kristian? Assigning to you and please feel free to reassign if you want to blame some other component.

--- Additional comment from pm-rhel@redhat.com on 2009-03-26 12:50:16 EDT ---

This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

--- Additional comment from tfu@redhat.com on 2009-11-03 02:12:38 EST ---

User krh@redhat.com's account has been closed

--- Additional comment from otaylor@redhat.com on 2010-06-22 17:23:40 EDT ---

I'm slightly guessing at what was being reported here. But with RHEL 6 Compiz I can reproduce a similar problem. With desktop-effects enabled:

 - Run 'gnome-session-save --logout-dialog'
 - Cancel dialog
 - Run 'gnome-session-save --logout-dialog' again

Dialog appears underneath all other windows. It has the "always on top" flag set (as you can see by looking in the window menu), but the flag was not properly honored when remapping an existing window from the withdrawn state. After moving other open windows out of the way, if you raise the window by clicking on the titlebar, you won't be able to lower it again.

--- Additional comment from otaylor@redhat.com on 2010-06-22 17:33:05 EDT ---

Actually, it's weirder than it getting the stacking order wrong in X terms - if you click where the window should appear you can click on the buttons, so the stacking order is right in X terms, but Compiz thinks its something different.

--- Additional comment from otaylor@redhat.com on 2010-06-22 20:09:09 EDT ---

I've put a patch and full explanation at:


It should be a very safe fix. Priority is in my opinion moderate:

 - It's a fairly confusing bug. 

   (In some circumstances you try to log out and nothing happens; this is 
   triggered by our input switching tool in an obvious way.)

 - It can't be that important if it hasn't been fixed upstream in ~5 years?

Not going to fix for RHEL 5, moving to RHEL 6

Comment 1 Bug Zapper 2011-06-01 15:51:13 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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: