GNOME Bugzilla – Bug 87744
stopped gtk apps don't get focus
Last modified: 2009-08-15 18:40:50 UTC
Package: metacity Severity: minor Version: 2.3.987 Synopsis: stopped gtk apps don't get focus Bugzilla-Product: metacity Bugzilla-Component: general Description: Description of Problem: GTK+2 apps, when stopped/frozen/deadlocked don't get the focus anymore. Steps to reproduce the problem: 1. gdb gnome-calculator and run it 2. when the window is mapped, press Ctrl-Z 3. try to focus the window with metacity Actual Results: the frame indicates that the window never gets focus Additional Information: I'm in sloppy-focus mode ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-07-09 10:02 ------- Reassigning to the default owner of the component, hp@redhat.com.
This is genuinely a broken UI situation, but I don't know how to fix it; the way WM_TAKE_FOCUS (what GTK uses) works, GTK has to set the focus to its own app windows when metacity asks, so if the app is stuck... Just a property of windows that set WM_TAKE_FOCUS but don't set the input flag.
I dunno if it' really a bug. After all, a stuck app maybe shouldn't have focus. It's a good way to see the app isn't reactive.
Something I think we discussed some time ago was that metacity should, when it is focusing such a window, should initially focus a child of the toplevel that is a sibling of the client window; then metacity will get key events for the window even if the client isn't focused... allowing <Alt>space, etc. Of course, this does defeat the idea of the X designers that you could have genuinely non-focusable windows that wouldn't disturb the current input focus .... e.g. tool palettes.
That plan breaks for frameless windows though - nowhere to put a sibling. I don't think WM_TAKE_FOCUS really works for windows that don't get focus, since all windows have to be able to get focus in some way for keynav, and the app can't tell when focus should be allowed (maybe via alt+tab) and when not (maybe via mouse click).
See 90382
Fixing #90382 should fix by giving us a "focused for WM but not for X" state.
Batch adding GNOME2 keyword to Metacity bugs. Sorry for the spam.
A change to XFocusChangeEvent could fix this. According to the ICCCM, that event has room for a timestamp and previous_focus member which would eliminate the need for WM_TAKE_FOCUS. The recommendation to add those fields in the next revision seems to predate ICCCM 2.0. Gtk+, locally active, would use the FocusChangeEvent timestamp to set focus, as it does now on receipt of the WM_TAKE_FOCUS message. Stopped apps would be left with focus wherever the WM put it. Output-only windows, such as GOK, would still set the input hint to False, and would refuse focus by setting focus to the previous_focus window with the same timestamp. Drag sources and palette windows, which may reject focus on client area ButtonPress or clicks, would also set the input hint to False, so that good WMs would only set focus non-client-area events. They'd then see FocusIn for only non-client-area events and thus set focus with the timestamp as needed. Drag sources would use the timestamp from the unfettered client-area ButtonPress or ButtonRelease to set focus when no drag could be initiated. In this case, stopped apps would only receive focus for non-client-area events, but that's better than they do now. (If the event could just keep falling through to the WM frame in that case, it'd be perfect.) In all cases, apps would have the timestamps needed to set focus to mode-specific windows. (Gtk+ doesn't do this now, thus causing other noted problems.) As with the raiseless DnD policy I've been pushing, sloppy focus users would still be forgoing the benefits of a modern desktop.
I can't reproduce this (the window appears to get focus, and keybindings such as Alt+F4, Alt+F9, and Alt+F10 work). Is this still relevant, or did this get fixed somewhere along the way? If it's still relevant, could someone try providing some alternate explicit steps to reproduce?
Can't reproduce the bug with GNOME 2.8.1 from debian/sid. Maybe it was quietly fixed.
Okay, I'll go ahead and close it then but feel free to reopen if you observe it again in the future.