Regression: Opening a new terminal appears at back

[Dr. David Alan Gilbert]

Hi,
  This is a regression in 1.90 that disappears if I go back to 0.98.
If I open a new terminator it appears behind any other terminators that are running; in 0.98 it appears on top.

Typically I start a terminal by a window manager binding of ctrl-alt-t, but the same problem happens if I open a terminator and in that run

    sleep 2; terminator

the new one hides at the back.

Desktop: xfce
Distro: Fedora 25 (Package 1.90-1.fc25 vs 0.98.4.fc25)

Workaround: Disable DBus server (Right menu->Preferences->Global->DBus server)

[Egmont Koblinger (egmont-gmail)]

Also happens on Ubuntu Yakkety, Unity 7 desktop.

I have absolutely no clue where to start looking at this problem :P

[Egmont Koblinger (egmont-gmail)]

So... I have a pretty large terminator window (so that there's no chance to open a new one without overlap) and a gnome-terminal. gnome-terminal overlaps terminator. From gnome-terminal I type "terminator".

The old terminator window is rised to the top, overlapping both gnome-terminal and the new terminator window.

I guess there's an explicit code somewhere to raise the old terminator window to the front. If so, this code could be simply purged not to do so, or modified (fixed) to do for the new window instead of the old. (Presumably whichever the gtk2 version did.)

In window.py line 388, self.present() is called once when the first window is started up, twice when the second window is, and so on. Feels to me that it's called for all the windows, but should be called for the new one only. Just a guess, but it's quite suspicious to me.

Stehpen, do you feel like continuing from here? :)

[Egmont Koblinger (egmont-gmail)]

Sorry, correcting myself a bit: That self.present() is called once for the first window, and then exactly twice for all subsequent windows: first for the new one, and then for the original one. This latter step should not happen. (Also, where and why does terminator remember which window was the original?)

[Stephen Boddy (stephen-j-boddy)]

As mentioned on one of the other bugs, this is all cropping up because DBus is active by default now. So secondary windows are not launching a new process (0.98) which always comes to the front and gets focus. Instead the new process connects to DBus, requests a new window, then exits. The original process then opens the new window. That's the bit that needs fixing to pop to the front and grab the focus.

[Egmont Koblinger (egmont-gmail)]

I have a vague feeling about dbus. I do understand the concept of first terminator process (which opens the first window, and then this terminator process itself keeps running) vs. subsequent terminator processes (that just connect to the previous one, ask it to open a new window, and then immediately quit).

On the other hand, the concept of first window vs. subsequent windows shouldn't exist, they should never be handled differently. All the windows are handled by the same single terminator process, and it's even possible to close the first after you've opened another. So the initial window should not be special in any way compared to any other subsequently opened windows, probably terminator shouldn't even be able to tell which one of its windows was the first.

[Stephen Boddy (stephen-j-boddy)]

No, the windows aren't treated differently. The first/second labeling is just so it's obvious that the code path followed for second windows is slightly different to the first window. This is mostly to do with initial startup and mainly is that options passed for the second window, pass through DBus first, and may conflict with existing state.

Bit further info. The DBus slightly abuses the create_layout function when the command line is used, opening a "default" layout. (You can actually launch a regular layout too with the appropriate command line option.) Unless a user has changed the default layout, this is a single terminal in a window. Layouts store the last active window/terminal so they can be activated when reopened. The last step of a layout is to present the window and set the focus to these stored values. But... (always a but) the default layout does not have one of these, and the original window has already stored itself in the variable. So, the original window presents itself.

I've now written a piece of code that mostly works, but there are it still has bad behaviour. Only sets the focus properly if you do not interact with previously opened windows. I think I need to "fix" the last_focused_term as well as the last_active_window.

The key seems to be calling set_keep_above(True), then set_keep_above(False) after the present() call. It may be that if I fix the terminal focus, that the set_keep_above calls will not be needed. Either way, I've had enough for the moment. This is just a brain dump for the record.

[Egmont Koblinger (egmont-gmail)]

I don't think set_keep_above(True) matters; in fact, it shouldn't be called at all if only "normal" (not maximized or quake-style or whatever) windows are used.

[Egmont Koblinger (egmont-gmail)]

When opening the second or subsequent window via "terminator" from cmdline, this happens:

First a new_window() is executed (not sure via which method calls exactly) which ends up calling window.py's show() with startup=True. This is okay.

Then terminator.py's layout_done() is called (again not sure about the entire path leading here). The very end of this method loops through all the windows and if finds the last active one then calls window.show() (with the implicit default startup=False) on that.

Either commenting out these four lines at the end of layout_done, or (probably equivalent) modifying window.py show() to prefix "self.present()" with "if startup:" seems to a be a big improvement and seems to fix the current problem.

Not sure about other side effects though, and other code paths that do requires this segment of code here. This would need a deeper understanding of the situation (for which I sure won't have time in the foreseeable future, sorry).

[Egmont Koblinger (egmont-gmail)]

Note: when opening terminator from another terminal emulator (e.g. gnome-terminal or konsole), it's still inconsistent to me whether the new terminator window gets focused, or the focus is kept at the one (gnome-terminal or konsole) which I'm using.

I'm not sure what it depends on, but I don't think it's terminator's business or fault. This seems to be a generic Gtk+ or window manager stuff. Even if I'm launching a different kind of app, e.g. firefox, if I'm just typing into gnome-terminal then firefox is presented at the back. I guess it's some generic protection (including some inconsistency in its implementation) that tries to prevent keypresses from unexpectedly going to a newly appearing app.

The code modifications outlined above seem to fix the problem for me if I'm executing terminator from within terminator to get a new window. I haven't tried hooking it up to some global shortcut or similar.

[Stephen Boddy (stephen-j-boddy)]

The following bug may have inadvertently led to a fix for a number of issues with focus and window z-order when opening new windows and unhiding a hidden one.

https://bugs.launchpad.net/terminator/+bug/1501128

Please retest revision 1715, and report if this bug is still reproducible.

[Jake Bailey (jakebailey)]

This still occurs for me on 1717. If I re-enable dbus, open Terminator, then use either my typical terminal-start keybinding (Super+Enter), or run terminator from terminator, it appears below my current terminal and is not focused.

However, it only occurs when my terminal is large enough such that the new instance would appear above the old one, which is my case is almost all of the time since I typically full-screen my terminal and open extra windows for one-off commands. If I instead keep the window small, and start it either way (keybinding or directly), the new window gains focus correctly, and doesn't appear below.

For reference, I'm on Arch with Cinnamon. If I simply disable dbus like the original post suggests, it works as expected, which says to me there's still something wrong.

[Stephen Boddy (stephen-j-boddy)]

OK, So I found the problem spot, and a simple one-liner prevents the original window popping to the front. However there is still a problem that the new windows do not get properly focused.

Committed revision 1718.

I'll leave the bug open till a full fix is found.

[Stephen Boddy (stephen-j-boddy)]

OK, So I think I found a fix for this. It is an old deep issue in gtk to do with timestamps and windows, and new windows from an existing process inheriting the existing windows timestamp. As a result focus stealing prevention places it behind the current focused window. Normally this is what you want, but in this case it isn't.

So my fix forces just the new windows to the front, but it has the minus that we're stomping over focus stealing prevention. There is probably a proper way to do this, but my eyes glazed over a bit as I was reading the bugs. So do I apply my size-ten-hobnailed-boot solution, or do I try and figure out how to do this the "blessed" way? Opinions?

Some supporting details:
https://bugs.launchpad.net/gala/+bug/1220179
https://bugzilla.gnome.org/show_bug.cgi?id=149028
https://bugzilla.gnome.org/show_bug.cgi?id=149276
https://bugzilla.gnome.org/show_bug.cgi?id=721145
https://bugzilla.gnome.org/show_bug.cgi?id=752000

[Stephen Boddy (stephen-j-boddy)]

OK, So it turned out the fix was not yet complete. We also needed to ensure that the active window was on top and focused... Oh boy, what fun that was to figure out. The windows get a timestamp, but even if the timestamps are in the right order, and you pop them up in the right order so that the last active is the last one popped, you can't guarantee that that is the one that will end with the focus. Instead we have to pop all the windows up, then find the last active one, then we need to repeatedly flush the pending events, and focus the window. If we don't do this we get semi-random window focused. Even doing all this is not 100% reliable, but I'm at the end of my tether trying to figure out why the wrong window is occasionally focused.

I'm going to push it to the repo so some more people can try it. Hopefully someone can suggest an improvement that fixes the occasional issue. But I do need some feedback if this fix is OK.

Committed revision 1744.

[zub (zub-linux)]

I've been seeing this issue with debian + xfce. The issue is gone with version 1.91, at least for me.

[michael gaspar (slovv)]

problem persists with version 1.91 on ubuntu with LXDE.

[Patryk "LeadMan" Benderz (leadman)]

I can confirm this on:

patben@patbenamd:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty

patben@patbenamd:~$ apt-cache policy terminator
terminator:
  Zainstalowana: 1.90+bzr-1705-1
  Kandydująca: 1.90+bzr-1705-1
  Tabela wersji:
 *** 1.90+bzr-1705-1 500
        500 http://pl.archive.ubuntu.com/ubuntu zesty/universe amd64 Packages
        500 http://pl.archive.ubuntu.com/ubuntu zesty/universe i386 Packages
        100 /var/lib/dpkg/status

[Sertac TULLUK (stulluk)]

This bug is still easily reproducible with debian9 + xfce.

Disabling dbus via "-u" argument fixes it.