Caps lock as modifier triggers viewport scroll

[kouyk]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

wayland / KWin / mutter

WezTerm version

20240205-070437-39d2b6ca

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Same issue as #3306; it was not resolved, since since it's locked I have to open a new one.

8c975a76810bf6de4a37ef4d43a538c3a7cfce18 was supposed to have fixed this, but the type of key is termwiz::input::KeyCode, so the correct is_modifier method that should have been edited to include CapsLock is actually the one in termwiz/src/input.rs

I can confirm that after adding CapsLock to the list, the bug no longer appears. It's kind of strange that there's (at least) 3 copies of is_modifier floating around in the code.

To Reproduce

same as #3306. Scroll up in the scrollback and press CapsLock;

Configuration

no config

Expected Behavior

expected behaviour is that nothing happens, actual behaviour is that the viewport scrolls to the bottom as if I typed something.

Logs

No response

Anything else?

No response

[wez]

Would you mind sharing the diff that you came up with?

[kouyk]

diff --git a/termwiz/src/input.rs b/termwiz/src/input.rs
index 6d52625e4..1645e0324 100644
--- a/termwiz/src/input.rs
+++ b/termwiz/src/input.rs
@@ -235,6 +235,7 @@ impl KeyCode {
         matches!(
             self,
             Self::Hyper
+                | Self::CapsLock
                 | Self::Super
                 | Self::Meta
                 | Self::Shift
diff --git a/wezterm-input-types/src/lib.rs b/wezterm-input-types/src/lib.rs
index b3298bad6..8de1ab52d 100644
--- a/wezterm-input-types/src/lib.rs
+++ b/wezterm-input-types/src/lib.rs
@@ -861,6 +861,7 @@ impl PhysKeyCode {
     pub fn is_modifier(&self) -> bool {
         match self {
             Self::LeftShift
+            | Self::CapsLock
             | Self::LeftControl
             | Self::LeftWindows
             | Self::LeftAlt

[Tudyx]

I've got the same bug and I can confirm that the workaround described in https://github.com/wez/wezterm/issues/3306#issuecomment-1479565201 still works

[ninjalj]

@Tudyx @kouyk (cc: @schweikert from #3306)

The purpose of caps:ctrl_modifier is to have Caps Lock behave as a Control modifier, but still be able to distinguish it from the Control_L and Control_R keys in things like games and emulators.

An alternative if you don't need that last behavior is ctrl:nocaps, which transforms Caps Lock into an additional Control_L.

I've opened an issue and MR in xkeyboard-config to improve the description of caps:ctrl_modifier. See:

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/443

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/666

[kouyk]

The purpose of caps:ctrl_modifier is to have Caps Lock behave as a Control modifier, but still be able to distinguish it from the Control_L and Control_R keys in things like games and emulators.

This makes sense, though it is really just a workaround in the context of WezTerm. Even if caps lock is not remapped to anything the same issue persists, IMO the intuitive behaviour would be that it behaves similarly to other modifiers since nothing is really being typed.