GNOME Bugzilla – Bug 90382
Make focus tracking correct and reliable
Last modified: 2020-11-06 20:08:23 UTC
See the long FIXME comment in window.c:meta_window_notify_focus() that refers to this bug. We need to do this at some point, but it will take some pretty disciplined thinking through. In brief have to split apart tracking the X keyboard focus from tracking the "which window appears to the user to be focused" allowing us to make the X keyboard focus tracking strictly correct, and handle all cases precisely.
Since it probably isn't clear: the impact of this bug will be metacity (and as a result the pager/tasklist as libwnck reads from metacity) theoretically getting confused about which window is focused and highlighting the titlebar of the wrong window, or losing focus entirely. Also just the conceptual braindamage of the current setup probably explains some of the bugs in here about focus weirdness.
*** Bug 95747 has been marked as a duplicate of this bug. ***
Bug 95747 mentions a special case to check
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
lowering AP priority until we have clear examples of this bug's a11y impact.
*** Bug 123460 has been marked as a duplicate of this bug. ***
I have had some really weird focus problems with metacity which I'm guessing is due to this bug. It happens only rarely; I don't know what triggers it, a vague guess is two windows getting opened at almost the same time. Anyway when it is triggered metacity doesn't seem to know which window is focussed. When I hit Alt+Tab, the other window briefly comes to the foreground (for a split second), *without the window decoration*, and then the original window comes back again. The only way to get to the other window is to minimize both the windows first. Switching to another workspace and back doesn't work.
Arvind: Can you get a verbose debugging log for us? To do so: 1. Reduce your desktop to as few windows as possible to reproduce the bug 2. Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace 3. On stdout metacity will print the name of the logfile 4. Reproduce the bug as quickly as possible 5. Kill the metacity you started above to stop the logfile from growing any longer 6. Compress the logfile and attach it to a bug report I know that you might have a hard time reproducing it as quickly as possible and might need to leave this running metacity for a while in order to reproduce, but if you could do your best and then tell us the name of the windows that exhibited the bugs (perhaps even annotating the log), it'd be helpful. Otherwise, all I can say is that I've never seen that before. Havoc: Is this bug covered by doc/how-to-get-focus-right.txt combined with just tracking down all the individiaul cases where we don't follow that? Or is there something else this bug is also about? (The getting confused about which window is focused sounds somewhat like bug 154598 could help)
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Arvind: Sounds somewhat like bug 145131. That bug technically only covers lack of decorations, but it's an uninitialized variable case so who knows... However, that's a separate bug so if you can still duplicate your problem after applying the last patch in bug 145131, please open a separate bug.
There are only four bugs left that this is marked as blocking: bug 87744 - about stopped apps and which I can't reproduce bug 88194 - metacity doesn't get the correct window focused after restart, which I believe I can solve if the patch in bug 158626 goes in bug 88214 - a11y stuff may need notification for an app when keys are pressed on the titlebar of one of its windows (no one can see how this is related to this bug, as far as I can tell) bug 155450 - a tracker bug for general focus issues (i.e. doesn't count) So, the only issue I can find remaining with this bug is whether we truly want some kind of notion of split metacity focus vs. keyboard focus. A method for doing that is briefly discussed in bug 158626, comment 5. But I can't see any use for it at all at this point. There may be no further need for this bug report to remain open... Comments?
I looked at bug 88214 again; Havoc is the only person who thought that bug depended on this one. Personally I think 88214 can be fixed independent of further work on this bug.
The reason I thought 88214 was related is what Elijah mentions at the end of comment 12: split metacity vs. keyboard focus. The app window does not have focus in 88214, you can't focus an unmapped window. There's further discussion of this tracking bug on bug 158626 (and that bug is another of the "fixed by separate metacity vs. X focus" thing)
Remove old target milestones on old bugs; sorry for the spam.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Moving things to focus component. Sorry for spam.
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.