Xubuntu: newly opened windows are no longer placed on front

[Cruncher]

Binary package hint: xfwm4

Since Xubuntu 9.04, newly opened windows are no longer placed on top of the existing windows, but *anywhere* on the desktop, which means most of the time hidden below other windows, without any notification whatsoever that there is a new window. How can this be changed?
This happens with these settings:
"Focus follows mouse" enabled
"Automatically raise windows when they receive focus" disabled
"Automatically give focus to newly created windows" disabled <======= cause of problem

I explicitly disabled "Automatically give focus to newly created windows", because that's what I want, but since 9.04, this option now also no longer brings the window to front. If I enable this option, it works as expected, bringing new windows to front.

This essentially means that this option is broken in 9.04, because the system is not really usable anymore with that option disabled.
This worked fine in 8.10.

[Charlie Kravetz (cjkgeek)]

If I understand this correctly, you disabled "Automatically give focus to newly created windows", expecting the system to give the new window focus? Does disabled mean unchecked?

I think that if the window is to be brought to the front on opening, it must have focus. That is the expected behaviour of the system. Any window that does not receive focus does not open on top of any other window.

If a window opens with focus with "Automatically give focus to newly created windows" disabled (unchecked), the option is not working because you have explicitly told it not to give focus.

[Cruncher (ubuntu-wkresse)]

Thank you for your response.
Yes, with "disabled" I mean "unchecked".

[hm, the following argumentation has gotten rather long, sorry, but please bear with me]

No, I do not want the new window to have focus. But it doesn't make sense to open a new window somewhere in the background, where it is hidden by other windows, up to the point where you keep waiting for the program to launch, wondering about whether something is broken, only to realize after some time that the window was launched correctly - just invisibly behind all others.
This is especially apparent for several system utilities opening subwindows: you wait forever for something to happen, but the new window has been there all along - *behind* the main window...

If I request an application to start, I expect to see the window, because I want to do something with it. Now, you could argue the same way about the focus thing: "If I request an application to start, I expect it to have focus" - well, not for everyone. I almost exclusively work with X-terminals, so generally I launch applications from the CLI with the '&' background option. Applications take a while to launch, and I don't want this to impede my work, so I don't want them to have focus, even when they do eventually pop up. The *user* should decide whether he wants to give focus to something, by moving the mouse (or in the default setup, by explicitly clicking a window).
In addition, as mentioned, this worked perfectly fine in both Hardy and Intrepid: new windows popped up somewhere on the desktop, did not steal focus, but still popped up in front of other windows.

The correct definition and expected behaviour I wish for and worked with for many years is: "the current focus is wherever my mouse pointer is", because I put the mouse there and that's where I want to do something. Windows should not steal focus just because they pop up somewhere, this breaks the consistency that focus is where the mouse pointer is.
With the current configuration options, this concept is not possible to realize.

I realize that the whole problem is a "don't care" for 98% of all users, since they use this awful Windows-like default behaviour of "click-to focus" instead of "focus-follows-mouse", but the new behaviour in Jaunty makes the configuration setting "Automatically give focus to newly created windows" useless, because having windows popup in the background is not desirable.

Proposing a possible solution (besides windows being *always* forced to pop up in front, which would be fine by me):
The actual option that is missing (and I seem to remember having seen exactly this option in a pre-9.04, probably GNOME, not sure) is "Open new windows in front". This would be the most flexible setting satisfying everyone: you can emulate the behaviour you described (new windows receive focus and pop up in front), you can configure the setting I describe (no focus, but still pop up in front), and you could even have the current Jaunty behaviour, if there are people who desire it (no focus, and pop up in background).

[Porcelain Mouse (pmouse)]

Second.

I find this a serious problem because I use Xfce and XUbuntu mostly for just this feature. I like to be able to click in a window without raising it and I do NOT like pop-up/unexpected windows to steal focus. Xfce makes this possible and I think its perfect. To avoid a religious war, let us all agree that all of these styles are equally valid.

Cruncher does a good job explaining why this bug is important, but I just wanted to add that this bug is very new. This behavior is aberrant and I do not think it has anything to do with the settings. New windows should always and have always come to the top of the normal stack space. The meaning of don't-raise-on-focus and don't-focus-new is clear and longstanding.

I'd be happy to help if someone could point me in the general direction.

[András Korn (kornandras)]

FWIW, I think the configuration pertaining to new windows should include the following options:

 * don't raise, don't focus;
 * raise, but don't focus (currently missing);
 * raise and focus.

For completeness, "focus but don't raise" could be included, but I don't think it makes sense.

As things are now, the datetime applet is next to useless, because the calendar clicking it pops up is placed behind the other windows, so it's only visible if you minimise all other windows first (which is another annoyance caused by this bug/missing feature).

"Raise but don't focus" should be implemented so that even if the new window were to pop up under the mouse, it shouldn't get focus until the user actually moves the pointer.

[Porcelain Mouse (pmouse)]

Despite the fact this bug was reported (in multiple bug reports), the Xfce team seems to be unmoved. All bugs were closed earlier this week, status: Invalid. Their claim is that this behavior--raise new widows regardless of focus--is incorrect, despite the extremely longstanding nature of this behavior and the fact it was a user configurable behavior. I've been over this many times and I cannot comprehend the unexplained assertion by the Xfce team that the behavior I like is just wrong and was impossible to preserve.

This behavior change *might* be a side effect of the following "improvement," listed in the 4.6 Changelog: "Do not automatically give focus to windows placed on lower layers, but focus those on upper layers at first map."

Will the maintainer for this Ubuntu package please help? What are the plans for this bug (in Ubuntu)?

[Matthew Caron (matt-mattcaron)]

I had originally filed #371454 which appears to be a duplicate of this.

Pulling in the context of a comment from that ticket, it looks like this was a requested behavior, based on this ticket:

http://bugzilla.xfce.org/show_bug.cgi?id=3200

Aside from that, I'm going to add my voice to the chorus saying "please give me an option to make it work like it did pre 4.6".

[Porcelain Mouse (pmouse)]

Great catch, Matthew. This is the history I was missing on this whole ordeal.

Bug 3200 is actually a feature request. In it, the claim is made that new windows popping to the top of of the Z-buffer is a inconvenient and a security risk. Well, obviously, the requester and I disagree on what is inconvenient. But, putting aside this subjective claim, I cannot accept the idea that locating new windows at the bottom of the Z-buffer (window stack) is *more* secure. The bug history show no indication it resulted in a feature change and I see no debate of the validity of this security claim.

I don't suppose Z-location has much to do with security, ultimately, since there are probably still ways to hide windows or launch window-less applications. But, if a new window is created, I don't think it placing it below existing windows is a secure option. Isn't it a greater risk to be unable to see newly created windows?

Moreover, if a new window goes on top of the stack, you can at least bring your last window to the top immediately with ALT-TAB. Or, you can lower the new window down to the bottom with CTRL-middle-click (or whatever is your hot-key for that action). If new windows go to the bottom, there is no recourse. You have to lower, shade, or minimize all the windows above it to see what happened. Furthermore, there are three Z-buffers, not one. If you want a window to always be on top of new windows that show up on the top of the "normal" window stack, you can just set the "Always above other windows" option for that window.

I still don't understand the logic of this change in the slightest.

I've opened another bug, hoping to have an earnest, open debate.

http://bugzilla.xfce.org/show_bug.cgi?id=5581

[Porcelain Mouse (pmouse)]

My apologies. There is, in fact, another recourse. It is possible to use the task bar (which I do not run) or the window list (from the desktop or tray) to locate any window, if you know it's title, already.

[Jarno Suni (jarnos)]

As for comment #4, there is another opinion: http://bugzilla.xfce.org/show_bug.cgi?id=5525
but I admit that an unexpected pop-up window that steals focus, if it is positioned under mouse pointer, could be annoying. AFAIK single alt-tab helps you to get the hidden window visible, if you know there is such a window.

When the windows manager tweak called "focus stealing prevention" is applied, I expect the focused window not to be covered by the new window. But to have that tweak applied, you have to enable it in settings, start application using startup notification (i.e. StartupNotify=true in its .desktop file), the involved applications have to support focus stealing prevention, and you have to interact with the focused window after you launch the other application, but before its window would pop up. That would be useful with applications that take long time to start, but in my experience, not all core applications support it, like Firefox, see Bug #211533

[Matthew Caron (matt-mattcaron)]

I should note that my solution to this problem (which renders XFCE completely unusable) was to switch to Gnome (whose window placement model was fixed right before XFCE's was broken). A couple of hours hunting up widgets, and I don't even notice anymore (and I switch between XFCE 4.4 on an old machine at work and Gnome on my machines at home on a daily basis).

That's the nice thing about F/OSS - when someone breaks a behavior on which you relied for years, you can kick them to the curb and find some other app which might even be better.

[Charlie Kravetz (cjkgeek)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Lucid Lynx. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

The development release of Xubuntu is available at:
http://cdimages.ubuntu.com/xubuntu/daily-live/current/

The following reports the issue fixed in Xfce, so I am changing the status to fix-committed as stated at https://wiki.ubuntu.com/Bugs/Status

From the upstream bug report:
http://bugzilla.xfce.org/show_bug.cgi?id=5479#c25

 Olivier Fourdan editbugs 2009-10-15 17:03:29 UTC

This is fixed in current git HEAD, closing. FYI Fedora has backported the
(trivial) fix in 4.6 too.

[Charlie Kravetz (cjkgeek)]

Verified the patch is not yet in Lucid.

[Lionel Le Folgoc (mrpouit)]

Upstream patches applied, should be fixed in the next update.

[Matthew Caron (matt-mattcaron)]

Confirmed fixed in Xubuntu 11.04 Beta 1.