GNOME Bugzilla – Bug 123460
Frame is painted as active when underlying top-level is not active
Last modified: 2004-12-22 21:47:04 UTC
Metacity displays top-level frame as active when it is not. It happens if you unshade Globally Active window. Run the attached test, several windows will be shown, double-click on the "Deny focus" to shade it - its frame will become focused. Double-click on the frame - window is unshaded but frame remains focused while window didn't set focus on WM_TAKE_FOCUS and no focus events arrived to window. Reproduced with metacity 2.4.55
Created attachment 20352 [details] test case for bug
metacity's idea of focus isn't quite the same as the X server's. You have to be able to "focus" shaded windows, output-only windows, and others that don't want X focus, so you can do Alt+space and other keynav with those windows. Really we also need the idea of "focusing" a minimized window, for bug #107072 See also bug #87744, bug #90382 I'm not sure this bug is a bug; if you ignore WM_TAKE_FOCUS the user can't keynav that window, as in bug #87744. With that bug though the broken keynav is only for broken apps that lock up. With your case of deliberately ignoring WM_TAKE_FOCUS, keynav is _always_ broken. On the other hand, drawing a window as focused when you won't really be able to type into it has its downsides. It's unclear exactly what to do here, bug #90382 amounts to "figure it out"
who is it that put gnome-access-bugs on the interest list? Is there a use case among the accessibilty utilities or ATs that exposeds this bug? As Havoc says, it's not obvious to me that there are actual accessibility use cases (for "non broken apps") of importance here. Maybe there are some important ones, but they aren't obvious.
Havoc, we don't just ignore focus. By this, we try to simulate MWM APPLICATION_MODAL behavior, the behavior Java had for several years on CDE and on Windows. When Modal dialog is shown, all other windows should be blocked. It means that it shouldn't be possible to focus them, raise them and so on. So while they are blocked we ignore WM_TAKE_FOCUS and thus make dialog "look" like it is truly modal. It hasn't been causing any accessibility problems for years and I don't think it'll cause them now. But this bug causes focus problem - the window which is not focused looks so, the window which should be focused(modal dialog) looses focus and focus is effectively nowhere at the moment.
Bill - I added access-bugs, since there seem to be a11y concerns that factor in to this decision. Denis - my feeling is that to get the "can't focus modal-shadowed windows" behavior we need to add that logic to the WM so metacity knows not to try to focus those windows. If there's no bug on that already let's create one specifically for "when trying to focus a modal-shadowed window, focus its modal transient instead"
well, it is not exactly what we want - anyway Java has non-focusable windows and anyway we'll get bugs with users complaining that IT IS possible to focus them and to loose focus because of them. But if you feel it is simplier to fix the particular "modal-shadowed" issue then it is ok with me since anyway what you propose is that's what I am doing right now as a workaround in Java code. I'll file a bug tomorrow.
I don't think there's a separate bug here vs. the general "figure out focus" bug. *** This bug has been marked as a duplicate of 90382 ***