Bug 513281 - In some circumstances new windows don't get focus and are obscured by old windows
In some circumstances new windows don't get focus and are obscured by old win...
Status: NEW
Product: metacity
Classification: Other
Component: general
trunk
Other All
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-01-30 21:29 UTC by Tony Houghton
Modified: 2008-10-25 14:47 UTC (History)
2 users (show)

See Also:
GNOME target: ---
GNOME version: ---


Attachments

Description Tony Houghton 2008-01-30 21:29:07 UTC
Please describe the problem:
When raise_on_click is false certain windows don't get focus when they are opened so they get placed behind the focus window, often meaning they are completely obscured and it appears as if nothing has happened. When raise_on_click is True, or when using other window managers, these same windows get focused and placed at the top of the stack.

I think this is a side-effect of meta_window_notify_focus() calling meta_display_(un)grab_focus_window_button() because if I stop it from doing that the problem goes away but I don't understand the grabbing issue well enough to come up with a proper fix.

Steps to reproduce:
1. Configure with metacity raise_on_click = 0 (and focus_mode = sloppy or mouse)
2. Open claws-mail
3. Click Compose


Actual results:
Claws-mail's main window keeps the focus and the compose dialog opens behind it.

Expected results:
The compose dialog should be focused and opened above the other window(s).

Does this happen every time?
The problem is repeatable each time I re-run claws-mail, but if I close the compose dialog and open it again it opens focused and raised.

Other information:
As well as the claws-mail example another situation I've found triggers the problem is a case where in response to a dialog button being clicked a dbus message is sent to another program, asking it to open another dialog, which is modal; the first program blocks on the dbus call, so its dialog doesn't get closed until the second program closes its dialog, and with metacity and raise_on_click = 0 the first dialog keeps focus instead of the second one grabbing it.
Comment 1 Tony Houghton 2008-03-03 18:29:15 UTC
I'm disappointed by the lack of response. Is this something metacity can't get right without causing something like bug 102209?
Comment 2 Elijah Newren 2008-03-04 05:28:52 UTC
I can't reproduce.  I installed claws-mail, ran 'claws-mail' in a terminal, click on the compose button, and the compose window comes up focused and on top.

For reference:
$ gconftool-2 --get /apps/metacity/general/raise_on_click
false
$ gconftool-2 --get /apps/metacity/general/focus_mode
mouse
Comment 3 Tony Houghton 2008-03-04 14:24:52 UTC
It's still getting it wrong for me; I usually use sloppy focus but I tried mouse  too. I had metacity running via a terminal this time and saw these error messages when I opened the compose dialog, I don't know if that's relevant:

Window manager warning: last_focus_time (1204640458) is greater than comparison timestamp (421518).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
Window manager warning: last_user_time (1204640458) is greater than comparison timestamp (421518).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
Window manager warning: 0x1200003 (tony@local) appears to be one of the offending windows with a timestamp of 1204640458.  Working around...
Comment 4 John Ng 2008-10-25 14:47:01 UTC
I am using Win XP, GIMP 2.6.1
similar problem happens too

1. open gimp, then load any image
2. open any application
3. click the window of the new application

result: the new application does not come to front








Note You need to log in before you can comment on or make changes to this bug.