GNOME Bugzilla – Bug 332385
New windows appear over the active windows, then go to the background
Last modified: 2006-09-13 22:25:34 UTC
Please describe the problem: New windows show in front of the active window for a short amount of time, then go behind it, as they should have initially Steps to reproduce: 1. Open a maximised window (epiphany/nautilus/termial/etc) 2. Start a different application, and, before it opens, give focus to the first application Actual results: The second app flashes in front of the first one for a brief time, then goes to the background. Expected results: That the second app starts in the background, without disturbing the work in the active window. Does this happen every time? Yes Other information:
I confirm this buggy behavior. On the other hand, I don't agree in the expected result. Usually a window appears because _I_ wanted it to appear. In this case it's much better if it appears in the foreground and even gets the input focus (as it was in gnome 2.12). There might be situations of course when it's not desirable and it would better stay in background. Maybe the best solution would be to introduce a WM attribute that tells whether the user expects this window to appear or not, modify all the applications according to this, and modify metacity to support this bit.
I can reproduce the flashing behaviour on FC5 with metacity-2.14.0. Having the first window maximised isn't necessary, it just makes it more obvious.
*** Bug 337752 has been marked as a duplicate of this bug. ***
This might just be another instance of bug 326159. I can definitely reproduce it when I'm launching a window from, for example, a terminal.
No, this bug is about whether it flashes on top before going below (see the first comment). Bug 326159 is about whether it should end up on top or end up on bottom. It sounds like we just have the code for stacking the new window just below the focus window too late; we'll have to move it earlier to make sure it happens before showing the window.
meta_stack_add() adds the window to the top of the stack (puts it above other windows), while meta_window_show() calls XMapWindow() _before_ trying to lower it to where it needs to be (via meta_window_stack_just_below()). That's the cause of the bug. Fixing it should be a good task for someone new.
Created attachment 65416 [details] [review] Fixes the no focus new window flash
Thanks for the patch. However, it looks like there was a little misunderstanding. The bug is that the window appears above everything else before being lowered to the proper position, not that the window is lowered. (There are other bugs where windows aren't getting focus when they should and as a side effect are getting placed below other windows, but the correct fix there is to find the reason it isn't getting focus on map and fixing it).
Sorry, perhaps it was my bad choices of words for describing the patch. The patch I submitted does fix the problem that you are talking about in the cases that I've tested it under. After applying the patch, if you run a program and quickly give focus to another window before the program starts, it will no longer "flash" in front before being correctly lowered to where it should be.
I went back and checked it out again. Instead of duplicating code for stacking I re-arranged the order in which the calls were initially made, yielding the same result. I'll attach this patch instead.
Created attachment 65503 [details] [review] Computes window stack before XMapWindow() calls
Oooops. I shouldn't have tried to look at the patch in a hurry and when I was tired; for some reason I thought I saw a bunch of minuses instead of pluses and thought you were just removing the meta_window_stack_just_below() call as opposed to adding another one. I was obviously pretty confused. Anyway, the old patch would mean we were trying to restack the window twice, which is somewhat wasteful, but otherwise should have been just fine. With the new patch, I'm worried that it'll fail due to trying to set focus to the window before mapping it. I think we have to carefully make sure that we get the order correct: stacking -> mapping -> focusing. Let me check with Havoc or Søren to be sure on that, though...
From email from Havoc: SetInputFocus won't work on an unmapped window; I don't remember if it does nothing or generates an X error, but I'm pretty sure it won't work. So, the new patch doesn't work because it puts the meta_window_focus() call (for the cases where it is called, anyway) before the XMapWindow() call. So we'll need something inbetween your two patches. (Oh, and if you want to reuse your first patch, don't forget to take whether the window overlaps the focus window into account as the code elsewhere in the function already does). Sorry for the scatter-brained reviews. Thanks for working on this. :)
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/33879
Created attachment 72562 [details] [review] Move stacking code up before map/focus This moves stacking code and overlap check up before the window is mapped/focused.
The window may not yet be placed, in which case moving the code this early causes the overlap computation to be faulty.
Created attachment 72567 [details] [review] Move stacking code after placing and before map/focus Oh, naturally. Doh. Patch moves the stacking code after placing
Looks good to me, thanks. :) 2006-09-13 Elijah Newren <newren gmail com> * src/window.c (meta_window_show): Patch from Thomas Andersen to make windows be stacked correctly before showing them, to prevent flicker with focus stealing prevention. #332385.