bug: Cannot go to register or top-level menu when using Fedora & Wayland

[dannyfritz]

Did you check docs and existing issues?

• [X] I have read all the which-key.nvim docs
• [X] I have searched the existing issues of which-key.nvim
• [X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

> nvim -v
NVIM v0.10.0
Build type: RelWithDebInfo
LuaJIT 2.1.1713773202
Run "nvim -V1 -v" for more info

> bat ~/.config/astronvim/lazy-lock.json | rg which
  "which-key.nvim": { "branch": "main", "commit": "a86e9d3c0023f985344014bf2b7cb15e0be8fa2b" },

Operating system/version

Fedora 40 w/ Wayland

> fastfetch --logo none
dannyfritz@raven-fedora
-----------------------
OS: Fedora Linux 40 (Workstation Edition) x86_64
Host: 20HDCTO1WW (ThinkPad T470)
Kernel: Linux 6.9.7-200.fc40.x86_64
Uptime: 5 days, 8 hours, 14 mins
Shell: fish 3.7.0
Display (AUO243D): 1920x1080 @ 60Hz [Built-in]
DE: GNOME 46.3.1
WM: Mutter (Wayland)
Terminal: tmux 3.4

Describe the bug

When using Fedora 40 and Gnome Wayland, which-keys dismisses itself after hitting <leader> + backspace. This is intended to show the top-level keymappings. This also happens when " is hit, the UI is immediately dismissed.

wl-clipboard might be related?

https://github.com/user-attachments/assets/edde2bc2-06b3-4106-a17e-7dd351b41d5a

Steps To Reproduce

1. Hit <leader>
2. Hit backspace

Expected Behavior

I expect to see the which-keys menu showing top-level keymappings.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "folke/which-key.nvim", opts = {} },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

[dannyfritz]

Potentially related: https://github.com/folke/which-key.nvim/issues/598

[folke]

That's weird indeed. I'm also using wayland and don't have this issuse. I'll push a debug mode later that will write to a log file. Will let you know when that's ready to further debug.

[folke]

Can you enable debug with opts.debug = true and report back the contents of ./wk.log?

[ljnsn]

I have the exact same issue. This is the log after pressing ":

on_key: "
State(start): { "Mode(n)", 'Node(")', { keys = '"', update = true, waited = 0 } }
  getchar
  on_key: <Esc>
  got: <Esc>

And this is after first pressing ', which works fine, and then <BS> to go to the top level.

on_key: '
State(start): { "Mode(n)", "Node(')", { keys = "'", update = true, waited = 0 } }
  getchar
  on_key: <BS>
  got: <BS>
  getchar
  on_key: <Esc>
  got: <Esc>
  reattach: { "<Esc>", "n" }
  feedkeys: { "Mode(n)", "<Esc>" }

[folke]

Damn ok, I think I know what's causing this. There's a bug/feature with wl-copy indeed where if you get its contenst it steals focus. which-key closes on focus lost.

I'm using hyprland, and there the issue doesn't exist, but I had a similar issue at some point with yanky on Gnome.

Will see if I can improve this.

[folke]

Should be fixed. Would be great if you can confirm

[ljnsn]

It is, thanks a lot! :zap: speed :D

[dannyfritz]

Also confirmed it is fixed. Thanks!

I believe this old issue is actually related: https://github.com/folke/which-key.nvim/issues/315