After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 487356 - meta_display_focus_the_no_focus_window() gets confused when there are buried fullscreen terminals
meta_display_focus_the_no_focus_window() gets confused when there are buried ...
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: Focus
trunk
Other Linux
: Urgent major
: 2.21.2
Assigned To: Metacity maintainers list
Metacity maintainers list
: 541129 559729 (view as bug list)
Depends on:
Blocks: 155450
 
 
Reported: 2007-10-17 02:12 UTC by Thomas Thurman
Modified: 2020-11-06 20:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas Thurman 2007-10-17 02:12:34 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.
Comment 1 Thomas Thurman 2007-10-17 02:32:57 UTC
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.
Comment 2 Elijah Newren 2007-10-17 03:33:33 UTC
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.
Comment 3 Thomas Thurman 2008-04-20 20:19:41 UTC
Moving things to focus component.  Sorry for spam.
Comment 4 Thomas Thurman 2008-07-01 20:30:09 UTC
*** Bug 541129 has been marked as a duplicate of this bug. ***
Comment 5 Thomas Thurman 2008-11-07 15:02:25 UTC
*** Bug 559729 has been marked as a duplicate of this bug. ***
Comment 6 André Klapper 2020-11-06 20:09:22 UTC
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.