GNOME Bugzilla – Bug 487356
meta_display_focus_the_no_focus_window() gets confused when there are buried fullscreen terminals
Last modified: 2020-11-06 20:09:22 UTC
== Presenting problem: == Suppose you have a terminal "A" open, and a main window belonging to another program "B", and "B" pops up a child window. I've seen this happen where "B" is firefox popping up some kind of alert, but in the testing this evening I've been using oowriter and the windows have been floating toolbars. Then, if "A" is fullscreen, when "B" pops up a window, "A" gets focus and gets raised. If "A" is not fullscreen, then "B"'s child window is displayed as you would expect. This is a current problem in trunk, and is trivially repeatable. It means that if you launch oowriter from a fullscreen terminal and move through a document with any kind of complex formatting, you will repeatedly be dumped back to the shell prompt (since floating toolbars appear and disappear as you enter and leave tables, bullet lists, numbered lists, etc). This makes the program almost unusable. I haven't yet investigated whether "A" can belong to other applications than terminals. == Analysis: == The windows created by "B" are handled specially in meta_window_show() because they are toolbar windows, and therefore have "takes_focus_on_map" and "place_on_top_on_map" false. Hence, they would ordinarily go through the "needs_stacking_adjustment" code, but they don't because they are descendants of the focussed window. The comment here, at window.c:2050, implies that this is only for dialogues. Possibly this means that toolbars should not have reached this point, but I doubt it because otherwise we could only carry out needs_stacking_adjustment on them which is clearly designed to prevent new windows from *overlapping* the focussed window, which toolbars almost always do. So if we assume that toolbars are supposed to have reached this point as well, we must reach the conclusion that something is different in the call to meta_display_focus_the_no_focus_window() if "A" is focussed (perhaps the screen's no_focus_window field is different). This is the current focus of my investigation; suggestions are welcome. I also need to figure out where "A" gets raised.
Rewrite last paragraph: So if we assume that toolbars are supposed to have reached this point as well, we must reach the conclusion that something is different in the call to meta_display_focus_the_no_focus_window() if "A" is FULLSCREEN (perhaps the screen's no_focus_window field is different). This is the current focus of my investigation; suggestions are welcome. I also need to figure out where "A" gets raised.
Window "A" probably isn't getting raised explictly, but implicitly. Check out stack.c:get_standalone_layer. Layers trump window->stack_position, so if the window is placed into the fullscreen layer the effect is that it gets raised relative to where it was before. Windows with the fullscreen hint are shuffled in and out of the fullscreen layer depending on where the focus lies; in particular, fullscreen windows return to the fullscreen layer when no window is focused. meta_display_focus_the_no_focus_window() naturally makes no window focused.
Moving things to focus component. Sorry for spam.
*** Bug 541129 has been marked as a duplicate of this bug. ***
*** Bug 559729 has been marked as a duplicate of 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.