New window looses focus, in background

Bug #1508531 reported by richman
42
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Terminator
Fix Released
Medium
Unassigned

Bug Description

Since the new 0.98 I experience a bug in on my laptop and my PC. I have in both cases XUbuntu 14.04 LTE and use the 3.13.0-66-generic kernel. The problem is the following:
After opening one terminator window (CRTL+ALT+T) and maximizing it, as soon as I want to open another new terminal window it is always behind the maximized window, except I already opened several windows, which are all put in the background of the maximized one, I somehow obtain a window which appears in the foreground.

Additionally if I open a terminal on one of the workspaces and maximize it, then switch to a different workspace and try to open a new terminal window, it sometimes happens that I get switched to the maximized windows workspace, but the new terminal is opened in the other one, too :(

I use xfce with the default windows compositor and the GTK2 version of terminator.

Personally it is a very annoying little bug, I hope it can be fixed/ figured out what is wrong.

Tags: focus
Revision history for this message
richman (heini89) wrote :
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

So I had a quick play. I can reproduce. It seems to be specific to when the DBus is used to open a new window. Ctrl+Shift+I is OK. The problem only occurs when you use the main menu to open a new window.

By the way, it is not necessarily only when the first window is maximised.

A temporary workaround is to disable the DBus interface. This can either be done in the Terminator preferences in the Global tab, or by adding the option "-u" to the launcher in the system menu editor. Note that this will increase resource consumption, because now, each time you use the launcher you will get a whole new process. It is better to use the shortcut for an attached instance generally if you want to keep resource usage low.

But there is something peculiar going on with xfce then with new windows. I'll set this to Triaged till I (or some other interested party) find the time to investigate further.

Changed in terminator:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Jan Groenewald (jan-aims) wrote :

On debian testing, whenever I have terminator open, maximized or not, future terminators open without focus.

Disabling dbus fixes it.

Revision history for this message
Jan Groenewald (jan-aims) wrote :

Ah, I see this in the terminator 1.90 changelog

    * Actually set the DBUs interface to on by default. For some
      reason it wasn't active by default.

That is why I only saw this the last two days. Might be nice to add a comment next to the Use DBUS interface checkbox about the focus issue.

Revision history for this message
Ilkka Rauta (irauta) wrote :

I'm on Debian Testing too, but use Openbox and see the same new behavior. After
some digging into the 1.90 source, I think I have an idea where the problem is.
However, I'm not very experienced with GUI toolkits or GUI programming, so take
this with a grain of salt.

In terminator.py, there is a loop (at line 365, method layout_done) that goes
through windows and calls show() on the window that's marked as
last_active_window:

    for window in self.windows:
        if window.uuid == self.last_active_window:
            window.show()

The last_active_window is set when the "focus-in-event" happens.

Looks like things go like this:

1. First window is created.

2. Method layout_done (in terminator.py) is called, but last_active_window
   is still empty so that window.show() line shown above does not get called.

2. The window gets a focus event as it has just been made visible, bringing it
   to foreground, so on_focus_in() (in window.py) gets almost immediately
   called, and the window gets marked as the last active window.

3. The second window is created, and I believe the the focus-in-event already
   gets posted into the application's event queue before layout_done is called.
   (There is a window.show() in terminator.py, method new_window, maybe it's
   the place that practically speaking triggers the focus event?) However, the
   event is not yet processed - on_focus_in is not yet called for the window.

4. Now layout_done is called again. The first window is still the one active
   according to last_active_window, so its window.show() is called in the
   loop I copy-pasted above. This call causes it to get focus again. Another
   focus event is queued.

5. Now that the window has been created and dbus method has completed, the
   events are handled in order, first the new window's on_focus_in is called
   and it is set as the last active window, but the next event right after it
   in the queue gets processed, and the first window's on_focus_in gets called
   too, and it overwrites the last_active_window and the same course of events
   can happen again from the point 3 onwards with other new windows.

Revision history for this message
Florent Thiery (fthiery) wrote :

Same here (Arch/Gnome 3), it seems related to the latest 1.0 release (includes GTK3 if i'm not mistaken).

1) open terminator on an empty desktop (ctrl+alt+t)
2) move to another desktop where a fullscreen app is already opened and focused (e.g. browser), open another terminator (ctrl+alt+t)
3) terminator appears hidden behind fullscreen app, gnome displays "Terminator <None> is ready" tooltip

If on #2 the browser is not focused, then in #3 terminator appears over it, but unfocused

The following log appears in journalctl -f:
déc. 19 16:14:44 x.x.x gnome-settings-daemon.desktop[861]: Unable to bind hide_window key, another instance/window has it.

I tried https://github.com/MichaelAquilina/gnome-shell-extension-stealmyfocus but it doesn't change a thing.

Revision history for this message
Florent Thiery (fthiery) wrote :
Revision history for this message
Florent Thiery (fthiery) wrote :

i also confirm that disabling "DBus server" is a workaround.

~/.config/terminator/config

[global_config]
  dbus = False

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

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.

Changed in terminator:
status: Triaged → Incomplete
Revision history for this message
Ilkka Rauta (irauta) wrote :

I tried revision 1715, but the focus issue still exists.

I tested this by opening xterm, runnin terminator from it (with the DBus server setting enabled), then opening another xterm and executing terminator from it too. A new window opens, but the one opened first one gets brought to foreground.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Hi Illka,

See:
https://bugs.launchpad.net/terminator/+bug/1646437, comment #15

1715 is actually quite out of date :-) I committed a fix there (rev. 1744) which I think fixes the background window issue, and only very occasionally focuses the wrong window. I haven't figured out the corner-case so far. Please check with that, as I'm fairly certain that will fix it for you.

Revision history for this message
Ilkka Rauta (irauta) wrote :

Just tested revision 1744, and the xterm test case from my previous comment now works as expected, newest window becomes the topmost one. Thanks for the fix!

If I happen to stumble upon any corner case (though my use of Terminator is pretty basic) and find a way to reproduce it, I'll let you know.

Changed in terminator:
status: Incomplete → Fix Committed
Changed in terminator:
status: Fix Committed → Fix Released
Revision history for this message
Sertac TULLUK (stulluk) wrote :

This bug is still easily reproducible with debian9 + xfce.

Disabling dbus via "-u" argument fixes it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.