Windows that don't accept window focus are focused on mouse click

[acrisci]

I know @Airblader looked at my previous implementation of focus handling and said he found some problems with it.

Consider this simple gtk application that makes a window that doesn't accept window focus:

// gcc -Wall gtk-test.c $(pkg-config --cflags --libs gtk+-3.0) -o gtk-test
#include <gtk/gtk.h>

int main(int argc, char *argv[]) {
    gtk_init (&argc, &argv);
    GtkWidget *widget = gtk_window_new(GTK_WINDOW_TOPLEVEL);

    g_signal_connect (G_OBJECT (widget), "destroy", G_CALLBACK (gtk_main_quit), NULL);  

    gtk_window_set_accept_focus((GtkWindow*)widget, FALSE);
    // make it floating
    gtk_window_set_type_hint((GtkWindow*)widget, GDK_WINDOW_TYPE_HINT_TOOLBAR);

    gtk_widget_show(widget);
    gtk_main();
    return 0;
}

This creates a floating window that should not accept input focus.

On Openbox, when you click this window, focus does not move from the previous window, although you can still interact with it to move it around and hit the close button (so it's not completely disabled).

On i3 when you click this window, it gets focus.

The behavior of openbox makes sense for floating windows but what about tiling? Should it just be completely skipped in the tree in this case? If so, doesn't that cause some user interaction problems because it's difficult to close without mouse bindings?

[Airblader]

Imho the proper behavior would be to focus the con internally but set input focus to the support window.

I'm pretty sure I covered this in an issue already but don't feel like looking it up on mobile. I'll take a look when I return from my vacation.

[Airblader]

From the referenced issue that I now closed in favor of this one:

This relates to #1784. For clients using the WM_TAKE_FOCUS protocol, we immediately update things like _NET_ACTIVE_WINDOW when sending the request. However, this will leave us in an improper state if the client rejects this request and doesn't set input focus.

We should not update the focus information in this case until we actually get notified, which will be in a FocusIn event.

[boblehest]

Any progress on this? I first noticed this issue a few years ago, but I didn't manage to trigger it very often, so it wasn't a huge issue. Now, I use an application (alacritty) that triggers it very frequently, and it's incredibly annoying.

[Airblader]

No, I don't think anyone actively worker on this yet.

[bryced-harper]

Bump this issue. I experienced the same recently, and each time I have to use $mod + Shift + R to restart i3.

[Airblader]

Please don't dump issues. If you want it to be resolved quicker, send a PR.

[bryced-harper]

@Airblader Sorry for that. Did you mean i3 will not officially resolve this particular issue ?

[Airblader]

Of course we will resolve it officially. Someone just has to actually send in the fix. But us maintainers have no roadmap. Personally I won't be working on this in the foreseeable future.

[JSkrat]

is there a way to prevent specific window getting focus at all, even with left-mouse-click — manually, in config? i intend to use i3 in some keyboardless touchscreen environment, so i need a virtual keyboard...

sorry if asking in not proper place, but i think it's related to that issue >_> it could be at least temporary solution, if it's possible

[Airblader]

is there a way to prevent specific window getting focus at all, even with left-mouse-click — manually, in config?

No, there is not.