Bug 491982

Also on Fedora 40, but with all KDE software built from source, I can't reproduce this issue as you've described it: Caps Lock succeeds at cycling through keyboard layouts in all apps, including Flatpak ones (tested Discord sand Telegram).

While testing this, I also noticed something weird: pressing Caps Lock not only cycled through layouts, but also actually engaged the normal Caps Lock behavior, so every other I pressed it, allletters would become uppercase.

I assume you've found a way to disable this behavior, as it's super annoying. Could you share how you did that? I suspect it may be the cause of the issue.

(In reply to Nate Graham from comment #1)
> Also on Fedora 40, but with all KDE software built from source, I can't
> reproduce this issue as you've described it: Caps Lock succeeds at cycling
> through keyboard layouts in all apps, including Flatpak ones (tested Discord
> sand Telegram).
> 
> While testing this, I also noticed something weird: pressing Caps Lock not
> only cycled through layouts, but also actually engaged the normal Caps Lock
> behavior, so every other I pressed it, allletters would become uppercase.
> 
> I assume you've found a way to disable this behavior, as it's super
> annoying. Could you share how you did that? I suspect it may be the cause of
> the issue.

Hi Nate,

Regarding the issue in this report. I've tried a few more things and realised the problem is only with flatpak Electron apps (e.g. Freetube and Signal), as it works fine with flatpak non electron apps. Are those apps you mentioned electron based (I don't use Discord or Telegram).

I'm trying to install native (non flatpak electron app) to test and see if the problem is a combination of flatpak + electron or just electron. In any case there is a problem somewhere...

Regarding the Caps Lock actually triggering capital letters, it somewhat rings a bell but I don't remember having had this problem anytime recently. It behaves as expected, that is, Caps Lock triggers the temporary layout change, and Alt + Caps Lock triggers original Caps Lock functionality (capital letters).

Ok I was able to install Signal natively from this repo https://software.opensuse.org/download.html?project=network:im:signal&package=signal-desktop and the issue is present! So it's not a problem that occurs with flatpaks but with Electron apps. I'll have change the bug report title to reflect this.

Discord is an Electron app, yeah. And I can't reproduce the issue there, but I do get the issue with Capt Lock also triggering letter case. I'd suggest investigating your settings to figure out why pressing Caps Lock only switches layouts, and doesn't also trigger letter case changes. Maybe you have an additional setting for it set in the advanced keyboard keybindings page?

Created attachment 172814 [details]
Shortcut config 1

Created attachment 172815 [details]
Shortcut config 2

(In reply to Nate Graham from comment #4)
> Discord is an Electron app, yeah. And I can't reproduce the issue there, but
> I do get the issue with Capt Lock also triggering letter case. I'd suggest
> investigating your settings to figure out why pressing Caps Lock only
> switches layouts, and doesn't also trigger letter case changes. Maybe you
> have an additional setting for it set in the advanced keyboard keybindings
> page?

I've attached screenshots of my keyboard layout config. By default the Caps Lock (while pressed) shortcut to trigger keyboard layout change assigns Alt + Caps Lock to trigger the original Caps Lock function (this has been the case for ages, in Plasma 5 too)

And just to reiterate it case it got missed, the issue only occurs when I use the Caps Lock (while pressed). If I just change the layout by clicking on the system tray icon (which makes it change from us to fr), then the change applies and works for all apps (including electron ones).

(In reply to Gauthier from comment #7)
> (In reply to Nate Graham from comment #4)
> > Discord is an Electron app, yeah. And I can't reproduce the issue there, but
> > I do get the issue with Capt Lock also triggering letter case. I'd suggest
> > investigating your settings to figure out why pressing Caps Lock only
> > switches layouts, and doesn't also trigger letter case changes. Maybe you
> > have an additional setting for it set in the advanced keyboard keybindings
> > page?
> 
> I've attached screenshots of my keyboard layout config. By default the Caps
> Lock (while pressed) shortcut to trigger keyboard layout change assigns Alt
> + Caps Lock to trigger the original Caps Lock function (this has been the
> case for ages, in Plasma 5 too)

And in my case it works just fine (as intended and as it has done for years). Caps Lock changes the keyboard layout while I keep it pressed, while Alt + Caps Lock performs the original Caps Lock function (letter case change).

Are you sure you didn't select just "Caps Lock" as a shortcut for layout change instead of "Caps Lock (while pressed)"? 

This would also explain why you can't reproduce the issue with the Electron apps as it seems to only be a problem with "temporary" (e.g. while pressed) types of layout change. It works fine when the layout change is more permanent (like when changing the layout by clicking on the system tray applet).

Looking at the screenshots, these options are handled by xkb, and not by kglobalacceld.

Is this issue reproducible on x11? If not maybe this should be moved to kwin.

(In reply to fanzhuyifan from comment #10)
> Looking at the screenshots, these options are handled by xkb, and not by
> kglobalacceld.
> 
> Is this issue reproducible on x11? If not maybe this should be moved to kwin.

Thanks for the suggestion. I unfortunately cannot try X11 on my system right now. I'll try to wipe up a new VM in the next few days and test it out.

I cannot reproduce this issue. I tried VS Code (Electron), installed natively. I do not have issue with Caps characters either.

Distro: OpenSUSE Tumbleweed
xkeyboard-config: 2.42
Plasma 6.1.4

Could share your xkeyboard-config package version and your ~/.config/kxkbrc file, or at least its `Options` field? There are many XKB  options which may have their labels changed in different XKB versions.

(In reply to Wismill from comment #12)
> I do not have issue with Caps characters either.
Just to make sure we're on the same page. I don't have problems with Caps characters (i.e. writing capital letters works fine inside electron apps using the shift key). I have an issue with changing keyboard layout to write in another language using the "Caps Lock (while pressed)" shortcut in Electron apps (works fine in any other apps). I can reproduce using Signal Desktop, Jitsi or Freetube.

Though I guess it is to note that pressing Caps Lock in Electron apps does not change keyboard layout but also does not make capital letters, it just does nothing. The alternative shortcut Alt + Caps Lock to enable the original Caps Lock function (capital letters) does work fine inside Electron apps.

> Could share your xkeyboard-config package version 
I have version 2.41 installed

> and your ~/.config/kxkbrc
[Layout]
DisplayNames=,
LayoutList=us,fr
Options=grp:caps_switch
ResetOldOptions=true
Use=true
VariantList=symbolic,

I managed to reproduce this on Wayland like this:

1. Use discord from flatpak
2. Set two keyboard layouts
3. Click Key Bindings -> Switching to another layout -> toggle on "Caps Lock (while pressed), Alt+Caps Lock for the original Caps Lock action", then apply
4. Select text field in discord 
5. Type something, switch the layout
6. The old layout still stays on even the new one shows to be updated

I am not sure if this is KDE bug or Flatpak bug or Electron bug, but the keyboard layout state is not properly updated when the key is pressed down.

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.90
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.2
Kernel Version: 6.10.10-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 15,5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600

(In reply to Akseli Lahtinen from comment #14)
> I am not sure if this is KDE bug or Flatpak bug or Electron bug

I can reproduce on Electron apps not installed as flatpaks...so I'd say it's either an Electron or KDE bug. Though since other ways to change keyboard layout do work fine in Electron apps (like if you just click on the layout icon on the system tray), I have a tendency to think it's related to how KDE sends the signal of the layout change in Electron apps when using "while pressed" type shortcuts.

Are your problematic applications running with native Wayland support or X11?

I set *3* layouts us,fr,de

I tried using Chromium (*not* flatpack) in both case and I observe the following:
- chromium --ozone-platform=wayland: no issue
- chromium --ozone-platform=x11: pressing Caps,
  - Having first layout US active: Q gives Q (expected A), Y gives Z (expected Y);
  - Having second layout FR active: Q gives Q (ok) but Y gives Y (expected Z)

So it seems that the group modifier is applied twice. In the case without only two layouts, it actually wraps to the first layout, so you observe no effect.

But wait, I can observe this behavior in Gtk apps using e.g. `GDK_BACKEND=x11 gnome-text-editor` and Qt app e.g. QT_QPA_PLATFORM=xcb kate`.

This seems to be an X11 bug only. Keep in mind this is for a Wayland session only, I have not tried a proper X11 session.

(In reply to Wismill from comment #16)
> Are your problematic applications running with native Wayland support or X11?
> 
> I set *3* layouts us,fr,de
> 
> I tried using Chromium (*not* flatpack) in both case and I observe the
> following:
> - chromium --ozone-platform=wayland: no issue
> - chromium --ozone-platform=x11: pressing Caps,
>   - Having first layout US active: Q gives Q (expected A), Y gives Z
> (expected Y);
>   - Having second layout FR active: Q gives Q (ok) but Y gives Y (expected Z)
> 
> So it seems that the group modifier is applied twice. In the case without
> only two layouts, it actually wraps to the first layout, so you observe no
> effect.
> 
> But wait, I can observe this behavior in Gtk apps using e.g.
> `GDK_BACKEND=x11 gnome-text-editor` and Qt app e.g. QT_QPA_PLATFORM=xcb
> kate`.
> 
> This seems to be an X11 bug only. Keep in mind this is for a Wayland session
> only, I have not tried a proper X11 session.

I can reproduce this behaviour. I tried Chromium with --ozone-platform=wayland and it works fine.

The app I tried were ungoogle chromium, chromium, Signal Desktop, Jitis, Freetube and they are indeed not running native wayland. The issue is now solved for all of them as I have flags so they start with wayland. Thank you!!

I guess while this is a bug for X11 apps running under wayland, but whether or not it is worth fixing I'm not sure (niche case + workarounds available).

This should definitively  be fixed, as it is still common to use X11 apps on Wayland (and will be for long, maybe forever).

This could  also a symptom of a deeper issue a with the keyboard state.

I am quite sure that this is an upstream bug in xwayland, which was fixed in https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1758 but currently reverted in the 24.1 branch, see: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1781. 

You may want to try xwayland 24.1.5 which has the fix.