keepassxc not seeing any of window title on i3wm

ghost commented 3 years ago

Overview

I am using keepassxc version 2.6.2. I want to perform autotype, so i choose autotype tab and click the [+] button and i want to choose correct window title for my browser. But there is just 1 title: "i3bar for output DVI-D-1"

Steps to Reproduce

Work on i3wm
Open keepassxc
Create new entry
Choose autotype
Create new window accociation
See the problem in window title

Expected Behavior

There must be every opened app with its title

Actual Behavior

It shows me just ""i3bar for output DVI-D-1""

Context

I am using ubuntu 21.04 and i3wm i3 version 4.19.1

KeePassXC - Version 2.6.2 Revision: e9b9582

Operating System: Linux Desktop Env: i3wm Windowing System: X11

Screenshot

kneitinger commented 3 years ago

I too have experienced behavior similar to this. I recall in the past having the issue where nothing except perhaps the bar is present, but am not certain. Currently, I have an Alacritty window, 2 Firefox windows, and spotify open. The Window Title drop down shows my 2 display's i3bars, and all of the above windows except Alacritty.

@solar-core do you use picom or any other compositor by any chance? Not sure if its related, but I do have it running with a few rules that only apply to Alacritty.

In case its helpful, here is an xprop on my not-visible-to-keepassxc Alacritty window

M_HINTS(WM_HINTS):
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
_VARIABLE_REFRESH(CARDINAL) = 1
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING
_NET_WM_ICON(CARDINAL) =    Icon (64 x 64):
    (not shown)

WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified size: 800 by 600
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
WM_CLIENT_MACHINE(STRING) = "tilly"
_NET_WM_PID(CARDINAL) = 2679
WM_CLASS(STRING) = "Alacritty", "Alacritty"
XdndAware(ATOM) = BITMAP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0
_NET_WM_NAME(UTF8_STRING) =

versus the working Spotify window

_NET_WM_ICON(CARDINAL) =
I3_FLOATING_WINDOW(CARDINAL) = 1
WM_CLASS(STRING) = "spotify", "Spotify"
WM_NAME(STRING) = "Spotify Premium"
_NET_WM_NAME(UTF8_STRING) = "Spotify Premium"
XdndProxy(WINDOW): window id # 0x6000008
_NET_WM_DESKTOP(CARDINAL) = 3
_NET_WM_STATE(ATOM) =
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified location: 0, 0
_NET_WM_PID(CARDINAL) = 320122
WM_CLIENT_MACHINE(STRING) = "tilly"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING

Versions

KeePassXC - Version 2.6.4 Revision: 34a78f0 i3 - 4.19.2

droidmonkey commented 3 years ago

Take this to the i3wm folks, they are not populating the WM_NAME or _NET_WM_NAME atoms. We have no way of knowing the window name without that information and we won't be able to show you them for selection. Closing this as it's not our bug.

michaelk83 commented 3 years ago

@droidmonkey , from the pastes, they do fill WM_CLASS in an identifiable way, so maybe fall back to that when WM_NAME isn't available?

droidmonkey commented 3 years ago

Possibly https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-class.html

kneitinger commented 3 years ago

IIRC i3 itself isn't populating either of those fields, just using what each app reports themselves as. The alacritty example in my last message is 100% my own fault because I've messed up my dynamic window title config option.

I did notice something that might be potential issues on the KeePassXC side of things though. i3 has a concept of "workspaces", aka virtual desktops in everything else. If I open Firefox on workspace A, and Slack on workspace B, each app is shown in the auto-type window select drop down if and only if KeePassXC is on the same workspace as it. Not the biggest issue, but not quite intuitive.

With that in mind, @solar-core is your KeePassXC window on its own workspace? Can you also provide the xprop output of something that should for sure work, like Firefox or Chrome just to see if something is messing up WM_NAME before it gets to KeePassXC? If you've never used it before, run xprop in a terminal and once your cursor changes, click on the window you want to target.

Also when skimming the code, caught these blacklisted WM_CLASS values which would be cool to add i3bar to! Additionally, if testing reveals this key:value to be widely used, we could consider blocking anything with _NET_WM_WINDOW_TYPE = _NET_WM_WINDOW_TYPE_DOCK.

droidmonkey commented 3 years ago

Some good stuff here but I doubt we can break the workspaces "sandbox" if we aren't seeing them already. This seems to be a quasi security feature and not just logical isolation. Normally everything on the xserver is visible and queryable to everything else. Each workspace could be running its own xserver instance.

kneitinger commented 3 years ago

It's definitely not anything that is intentionally isolating in a security sense, just in a whats-being-drawn sense, and it is all just one xserver. Still, their tree structure, and the various logical containers it uses, might make traversing parent windows (my terminology might be slightly off here) too odd in the general X11 case to warrant having i3 specific logic in the auto-type window code.

I'm very familiar with how i3 represents its windows/workspaces/other-logical-structures within i3, so in a little bit I could have a more in depth write up about what, if anything, could be modified to support it here.

Edit: there are plenty of other applications, such as OBS, Zoom, and rofi that see these windows' presence just fine (even if they don't always know how to deal with windows that aren't currently being drawn :slightly_smiling_face:)

droidmonkey commented 3 years ago

A demonstration of the window tree would be great

kneitinger commented 3 years ago

There is a command i3-msg -t get_tree which will dump the current tree as JSON. Here is a link to mine. It's appears pretty complicated, and there is a lot of terminology, but I'll do my best to describe it!

Description:

i3 is a tiling window manager, where tiling is achieved by having containers (shown as "type": "con" in the JSON) that have horizontal or vertical layout, and can be filled with good old X11 windows, or nested containers for more complex tilings. There are also other container layout modes like tabbed and stacked, but we can safely ignore those for simplicity sake.
i3's representation of its entire visual/organizational state is a big tree with a root node at the top.
The children of a root node are outputs which are displays, such as eDP for my laptop screen, and maybe something like DP-0 for an external display. Only one output in this gist for simplicity.
The children of each output are workspacess. At any given time, a workspace belongs to an output and has a collection of containers and windows that belong to it, as well as a visibility flag. Only one workspace per output can be shown at a time, and workspace can only belong to one output at a time, but they can me moved around at will at any moment. For example, I can move workspace " 1 " from my left monitor to my right. The dock is also a child of an output, but thats not too important.
Once we're at the workspace level, things start to be more classical, if you will. We have an arrangement of windows (all wrapped in one or more containers). At this scope, the current KeePassXC window detection works fine, so long as the workspace is visible (even if visible on an output other than that of KeePassXC)

The JSON in that gist shows the following scenario:

One output, my laptop display (eDP), and the little dock at the top of the screen
Two workspaces: "1: 1 " and "2: 2 " with the following windows:
- 1 (Currently being shown at time of tree dump)
- Alacritty terminal emulator
- Firefox showing this very page
- 2
- Firefox showing Wikipedia homepage
To complicate matters, there is also a pseudo-workspace called the scratchpad that is good for windows you don't to necessarily see all the time. In this JSON, KeePassXC is in the scratchpad. It is implemented as a workspace with name __i3__scratch and scratchpad windows are drawn as floating windows over the active workspace when summoned.

Some of the values in the JSON are X11-based values (such as the "id" I think??) but most are i3-specific vars. I'll look into what is logically only in i3, versus what maps to an X11 feature. I want to reiterate that everything from the workspace level, down, can be moved at will. Workspaces moved to different outputs, windows and containers moved to different workspaces, so on and so forth.

I think the important missing piece is how i3 manages visibility and the notion of non-shown workspaces in terms of X11. I don't have any non-i3 X11 machines available at this very moment, but I'm curious if KeePassXC currently detects minimized (or minimized-to-tray) applications in something like Gnome.

kneitinger commented 3 years ago

Here is the xprop output of the not-currently-displayed Firefox (via the -id flag with its window ID) versus the Firefox that is currently shown

Not visible:

$ xprop -id 6310011                                      21-06-13 14:22:35 (0)
_NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 1020, 523
_NET_WM_DESKTOP(CARDINAL) = 1
_NET_WM_STATE(ATOM) =
WM_STATE(WM_STATE):
        window state: Withdrawn
        icon window: 0x0
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        Initial state is Normal State.
        bitmap id # to use for icon: 0x60488a
        bitmap id # of mask for icon: 0x604896
        window id # of group leader: 0x600001
_GTK_THEME_VARIANT(UTF8_STRING) =
WM_WINDOW_ROLE(STRING) = "browser"
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
XdndAware(ATOM) = BITMAP
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 6310013, 6310014
_NET_WM_USER_TIME(CARDINAL) = 88560575
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x60487c
WM_CLIENT_LEADER(WINDOW): window id # 0x600001
_NET_WM_PID(CARDINAL) = 2683
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "tilly"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified location: 0, 0
        program specified minimum size: 450 by 95
        program specified maximum size: 16384 by 16384
        program specified base size: 450 by 95
        window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Navigator", "firefox"
WM_ICON_NAME(COMPOUND_TEXT) = "Wikipedia, the free encyclopedia — Mozilla Firefox"
_NET_WM_ICON_NAME(UTF8_STRING) = "Wikipedia, the free encyclopedia — Mozilla Firefox"
WM_NAME(COMPOUND_TEXT) = "Wikipedia, the free encyclopedia — Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "Wikipedia, the free encyclopedia — Mozilla Firefox"

Visible:

$ xprop                                                  21-06-13 14:22:51 (0)
_NET_WM_USER_TIME(CARDINAL) = 91262150
GDK_TIMESTAMP_PROP(GDK_TIMESTAMP_PROP) = 0x61
_NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 1026, 1058
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_STATE(ATOM) =
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        Initial state is Normal State.
        bitmap id # to use for icon: 0x60481f
        bitmap id # of mask for icon: 0x604825
        window id # of group leader: 0x600001
_GTK_THEME_VARIANT(UTF8_STRING) =
WM_WINDOW_ROLE(STRING) = "browser"
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
XdndAware(ATOM) = BITMAP
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 6291461, 6291462
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x600004
WM_CLIENT_LEADER(WINDOW): window id # 0x600001
_NET_WM_PID(CARDINAL) = 2683
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "tilly"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified minimum size: 450 by 95
        program specified maximum size: 16384 by 16384
        program specified base size: 450 by 95
        window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Navigator", "firefox"
WM_ICON_NAME(COMPOUND_TEXT) = "keepassxc not seeing any of window title on i3wm · Issue #6524 · keepassxreboot/keepassxc — Mozilla Firefox"
_NET_WM_ICON_NAME(UTF8_STRING) = "keepassxc not seeing any of window title on i3wm · Issue #6524 · keepassxreboot/keepassxc — Mozilla Firefox"
WM_NAME(COMPOUND_TEXT) = "keepassxc not seeing any of window title on i3wm · Issue #6524 · keepassxreboot/keepassxc — Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "keepassxc not seeing any of window title on i3wm · Issue #6524 · keepassxreboot/keepassxc — Mozilla Firefox"

It seems like

WM_STATE(WM_STATE):
        window state: Withdrawn
        icon window: 0x0

versus

WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0

is a notable difference.

droidmonkey commented 3 years ago

A withdrawn window means it is not part of the active window list anymore. Minimizing a window in gnome and kde does not put it in a withdrawn state. https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.3.1

keepassxreboot / keepassxc