GNOME Bugzilla – Bug 155369
Metacity gives focus on window even when it is set as accept_focus = FALSE
Last modified: 2020-11-06 20:05:04 UTC
Usually, the attached simple window program do not gain focus under metacity. That's proper behavior. But if you double-click the title bar and roll-up, it gains focus. This bug affects input methods' candidate window.
Created attachment 32597 [details] gcc -o main main.c `pkg-config gtk+-2.0 --cflags --libs`
From meta_window_focus() in window.c: /* For output-only or shaded windows, focus the frame. * This seems to result in the client window getting key events * though, so I don't know if it's icccm-compliant. * * Still, we have to do this or keynav breaks for these windows. */ I'm guessing this is the problem. Any better solutions?
If shaded windows are really inconsistent with regular windows, I think basically we just need to see why regular windows work right and add the same rule while they are shaded.
Created attachment 60364 [details] [review] Only give focus to shaded windows which can take input (In reply to comment #3) > If shaded windows are really inconsistent with regular windows, I think > basically we just need to see why regular windows work right and add the same > rule while they are shaded. Regular windows work right because it checks the window->input flag before giving them focus. I'm not sure why we set input focus specially for shaded windows (it doesn't actually seem to affect keynav for all I can see), but the attached patch solves the present bug.
(In reply to comment #4) > Regular windows work right because it checks the window->input flag before > giving them focus. I'm not sure why we set input focus specially for shaded > windows It's not special checking for shaded windows; it's special checking for shaded windows (window->shaded) _OR_ windows that can't accept input (!window->input && !window->takes_focus). ;-) However, the reason for the special treatment of shaded windows is that the window isn't actually mapped so X won't let us focus it. Metacity's window (the frame that goes around the client window) is mapped, so we focus that instead. The reason for the special treatment of windows that can't accept input is to avoid breaking keynav (see below). > (it doesn't actually seem to affect keynav for all I can see), but the > attached patch solves the present bug. I believe that with this patch you will be unable to use Alt+Tab to switch to the window and then press Alt+F4 to close it; which will leave the mouse as the only way of closing. We can't break keynav like that. (Besides, if you did want to handle output only windows like this, it'd be clearer to modify the if above it). I think we have several other bugs open on this or similar issues. Bug 90382 (scroll down to comment 12 or so) talks about introducing a separate notion of metacity focus vs. keyboard focus to try to handle something like this. But I'm not even sure what the appropriate UI is for something like that, so I really don't have any pointers on where to go to fix this bug.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.