Activating a window with the foreign toplevel management protocol does not work

[lbonn]

Hyprland Version

System/Version info

Hyprland, built from branch main at commit 8c3613632a6ccebf9fb797ec756ecfce99514eec dirty (renderer: nuke lastFrameDamage and rework finalDamage).
Date: Fri Feb 23 02:02:32 2024
Tag: v0.35.0-83-g8c361363

flags: (if any)


System Information:
System name: Linux
Node name: xxxxxxx
Release: 6.7.5-zen1-1-zen
Version: #1 ZEN SMP PREEMPT_DYNAMIC Sat, 17 Feb 2024 14:02:21 +0000


GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation Crystal Well Integrated Graphics Controller [8086:0d26] (rev 08) (prog-if 00 [VGA controller])


os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo


plugins:

Bug or Regression?

Regression

Description

As reported in lbonn/rofi#117 and prasanthrangan/hyprdots#848, switching windows with rofi wayland does not work anymore.

Most likely it is a regression that appeared between 0.34 and 0.35.

Some WAYLAND_DEBUG=1 logs

[...]
[4034713.437] [email protected]_id("firefox")
[4034713.440] [email protected]_enter(wl_output@11)
[4034713.443] [email protected](array[0])
[4034713.446] [email protected](nil)
[4034713.448] [email protected]()
[4034713.452] [email protected]("New Issue · hyprwm/Hyprland — Mozilla Firefox")
[4034713.455] [email protected]_id("firefox")
[4034713.458] [email protected]_enter(wl_output@12)
[4034713.461] [email protected](array[0])
[4034713.464] [email protected](nil)
[4034713.467] [email protected]()
[...]
[4036114.703] [email protected](2512, 701403, 28, 1)
[4036114.788]  -> [email protected](wl_seat@8)
[4036115.823]  -> [email protected]()
[4036115.885]  -> [email protected]()
[4036115.933]  -> [email protected]()
[4036115.954]  -> [email protected]()
[4036115.961]  -> [email protected]()
[4036115.967]  -> [email protected]()
[4036115.973]  -> [email protected]()
[4036115.979]  -> [email protected]()
[4036115.985]  -> [email protected]()
[4036115.990]  -> [email protected]()
[4036115.996]  -> [email protected]()
[4036116.004]  -> [email protected]()
[4036116.011]  -> [email protected]()
[4036116.018]  -> [email protected](new id wl_callback@26)
[4036116.094] [email protected]_id(21)
[4036116.102] [email protected]_id(26)
[4036116.108] [email protected]()

activate() has no effect here, focus does not change.

How to reproduce

• install rofi with wayland support
• rofi -show window
• select a window to switch to and press return

Crash reports, logs, images, videos

No response

[vaxerski]

likely 17339e0

you need to:

• unmap your ls
• then issue an activate
• then do whatever else and exit

if you issue an activate while you still have a keyboard-exclusive LS open, it will be ignored.

[lbonn]

@vaxerski thanks, that was it and it looks like our use case mostly fits in pattern (destroy layer shell before focusing).

However, maybe this constraint is too limiting? Focus and keyboard interactivity can be orthogonal.

For example if someone wants to replicate a MS Windows' alt-tab like tool which activate windows on entry selection and stays displayed on screen. Disabling keyboard interactivity temporarily during the switch would be awkward in this case.

I could not really follow from the linked issues discussion if this new constraint is preventing some class of bugs / misuse?

[vaxerski]

make your layer's focus model ON_DEMAND then and not EXCLUSIVE.

[lbonn]

Well, in this case it mostly works (there is an issue with repeating key presses that I haven't really looked into) but then applications can steal the keyboard interactivity if the user clicks on them and that is not necessarily desirable for this kind of application.

Disabling activate() makes sense for a session locker but there is already the session lock protocol for that. What would be the use case for the current EXCLUSIVE behavior outside of a session lock?

[vaxerski]

precisely an app launcher.

then applications can steal the keyboard interactivity if the user clicks on them and that is not necessarily desirable for this kind of application.

that's why technically this should be a privileged protocol. The reason you even get it exposed is because I am kind enough to ignore that.

I don't see anything wrong here. Everything is done per-spec, you say it works, so I'll be closing this.

The behavior won't change. ON_DEMAND exists.

[lbonn]

Sure, thanks for spelling that out.