bugGKSu - Bugs: bug #11450, gksu window appears below other...

 
 

bug #11450: gksu window appears below other window

Submitted by:  None
Submitted on:  Thu 30 Dec 2004 08:06:12 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 01 May 2006 02:52:16 PM UTC, comment #2:

This has been dealt with some versions ago, please reopen if you still find the problem. Thanks for the very good bug report!

Gustavo Noronha Silva <kov>
Project Administrator
Tue 08 Feb 2005 11:32:43 PM UTC, comment #1:

This bug is no longer valid with the latest release.

Anonymous
Thu 30 Dec 2004 08:06:12 AM UTC, original submission:

I've submitted this bug to the Gnome Bugzilla (Bug #162461), but was pointed to this website as it seems to be a "gksu" bug instead of a "gnome" one.

My report was:
==================================================
Gnome version: 2.8.1
Metacity version: 2.8.6 (?)
gksu version: 1.2.2
Distribution: Debian unstable (2004/12/29)

Description:
------------
When you start "gksu" and that dialog ("Change User") is obscured by another application's window, it is not possible to bring the gksu-dialog in front so you can see it.

Apparently "gksu" 'blocks' the desktop and will only 'unblock' it when you enter a password. But when the gksu-dialog is not visible, there is no way of knowing that it is waiting for your input. Neither "ALT-TAB" or clicking on the minimize-button of the other application will work.

The "gksu"-dialog keeps focus and input, so typing the password blindly will still 'unblock' the desktop. But some users this will not be obvious and the desktop will just appear to be 'frozen' with nothing one can do about it.

What would I expect:
--------------------
Either:

  • The "gksu"-dialog is treated as any other window, eg the window-manager still works and you can ALT-TAB to it.
  • The "gksu"-dialog appears above all other windows, so it is always visible.

Steps to reproduce:
-------------------
- start an application that takes a while to show their initial window (eg it occured when launching 'pan').
- while this application is starting, start 'gksu' (eg: by clicking the "Root Terminal" icon).
- the 'gksu' ("Change User") dialog sometimes is hidden under the main-window of the other application. I suppose this depends on when exactly that window and the gksu-window appear.

Additional info (aka "My Guess Is(tm)"):
----------------------------------------
I suppose "gksu" grabs all input and doesn't allow the screen to update (eg: also the system-monitor applet freezes). Apparently there is a timeframe in which an application can still paint his window to the screen before "gksu" steps in and blocks such updates. When an application paints his window after the "gksu"-dialog but before "gksu" 'blocks' the desktop, the dialog appears below the application's one.

I understand why "gksu" is doing this 'grabbing' (because it doesn't want other applications to grab the users input (==password!) in the "Change User" dialog).

A fix would be:
- first block all other input and updates;
- and only then put the "Change User" dialog on the screen.

This way the "Change User" is always on top of things. I suppose it now does it the other way which leads to this timeframe where the "gksu" dialog can be obscured. The reason why it does it the other way now might be that it depends in some ways on the window-manager to do something for it (eg: paint the window-decorations) => it can't block the window-manager before it shows its dialog => there is a timeframe in which the window-manager (but also other applications) can show something on the screen. If this is the case: maybe "gksu" should paint his window himself, eg without window-decorations.
==================================================

I got following reply from a Metacity-developer:
==================================================
From Elijah Newren (newren AT gmail DOT com)

I took a quick look at the gksu code, and your suspicions are correct. The first ensure that their window is shown, then do a server grab. And they don't set an above state or anything. They should either behave like the libgnomeui logout popup (grab the server then show an override-redirect window that isn't under the control of the window manager), set an above hint, or jump on the wm-spec-list and request a new type of window if they want better support (i.e. maybe there can be a window type which, while mapped, prevents other windows from being mapped?).

Anyway, depending on the window manager to show the window without giving any hints about it's type, and then grabbing the server so that metacity is unable to do anything more isn't anything we can fix. Please report this bug to the
gksu developers. It appears there are links to their bug submission at http://www.nongnu.org/gksu/
==================================================

So I report this bug here instead.

It doesn't happen too often, but when it does, it is a bit surprising because the whole desktop is blocked with no visible way of unblocking it.

It can be easily avoided if the user doesn't click on anything else when she plans to click on a "gksu" icon later.

Kind regards,
Robrecht Jacques
Robrecht DOT Jacques AT advalvas DOT be.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Mon 01 May 2006 02:52:16 PM UTCkovStatusNone=>Fixed
  Open/ClosedOpen=>Closed

Back to the top


Powered by Savane 3.1-cleanup1