wl-clipboard steals focus from ddterm

[somepaulo]

GNOME Shell version

45.1

Session type

Wayland (echo $WAYLAND_DISPLAY output is non-empty)

Special configuration

• High DPI
• More than one monitor

ddterm version

48

Linux distro

Arch Linux

ddterm settings dump

[/]
background-opacity=0.93000000000000005
bold-is-bright=true
ddterm-activate-hotkey=@as []
ddterm-toggle-hotkey=['Insert']
hide-when-focus-lost=true
new-tab-front-button=false
notebook-border=false
palette=['rgb(23,20,33)', 'rgb(192,28,40)', 'rgb(38,162,105)', 'rgb(162,115,76)', 'rgb(18,72,139)', 'rgb(163,71,186)', 'rgb(42,161,179)', 'rgb(208,207,204)', 'rgb(94,92,100)', 'rgb(246,97,81)', 'rgb(51,209,122)', 'rgb(233,173,12)', 'rgb(42,123,222)', 'rgb(192,97,203)', 'rgb(51,199,222)', 'rgb(255,255,255)']
panel-icon-type='none'
pointer-autohide=true
preserve-working-directory=false
scroll-on-output=true
shortcut-toggle-maximize=@as []
shortcuts-enabled=true
show-scrollbar=false
tab-expand=false
tab-label-ellipsize-mode='middle'
tab-show-shortcuts=false
tab-switcher-popup=false
tab-title-template='{{window-title}}'
theme-variant='dark'
transparent-background=true
window-maximize=true
window-position='top'
window-resizable=false
window-size=1.0

Description

More often than not, I'd say 99% of the time, launching the micro editor, as well as selecting text in it with the mouse and middle-click-pasting into it makes ddterm lose focus and slide up, when hiding focus notifications with an extension.
Alternatively, with no other extensions enabled, ddterm stays visible, but does not show micro or the pasted text, and the notification wl-clipboard is ready appears.
Pressing the ddterm hotkey (twice in the second case) brings it back again with micro open and the text selected/pasted.

This problem doesn't happen with nano, vim or other input-enabled TUI apps, like mc or pacseek.
So the problem is obviously with micro using wl-clipboard and with the latter grabbing the focus and making ddterm lose it.
Curiously, however, very rarely, this stops happening with no particular traceable action on my side, and apparently remains that way until the end of the particular shell session (closing the ddterm tab).
Also, this didn't happen in Gnome 44, and it's been a thing since the ESM port became available on git. I was hoping it would go away once the port is finalised and published on EGO, but I still have it.

[amezin]

wl-clipboard creates a temporary window and expects it to gain focus. See #622

1. If "above all windows" mode is enabled in ddterm, wl-clipboard will hang.

2. If "hide when the app loses focus" is enabled (hide-when-focus-lost=true in your config), ddterm will hide when you try to use wl-clipboard.

This is a consequence of how wl-clipboard is implemented, and at least "above all windows" can't be fixed with current Mutter API at all. (2) maybe can be fixed if ddterm would detect wl-clipboard specifically and ignore it.

[somepaulo]

Thanks for explaining.
I'll stick with pressing the hotkey for now. Or maybe disable the hide-when-focus-lost setting.

[amezin]

Actually, if we could detect wl-clipboard window, it should be possible to disable ddterm's "above all windows" temporarily, and activate wl-clipboard window

The problem is I'm still not sure how to detect/find the window

[amezin]

bugaevc/wl-clipboard#205

[masmu]

I just patched and rebuild wl-clipboard myself and added your app id and class attributes.

Is there any patch or piece of code for ddterm available to test out whether the issue is fixed?

[amezin]

Is there any patch or piece of code for ddterm available to test out whether the issue is fixed?

No, nothing has been implemented in ddterm yet

[ram-on]

Hi @amezin I'm still having this issue, both when launching micro and when executing wl-copy 'hello': i.e. in both cases, ddterm loses focus.

GNOME: 47.1
ddterm: 55
(Using Wayland)

[amezin]

@ram-on please create a new issue

And I don't know what micro is