capslock is released automatically

[alotbsol555]

possible bug: capslock is released automatically, which should not happen. casplock should be active until released manually.

steps to reproduce (autocapitalizatiol of sentences is turned off, capslock icon is on the shift key)

1. go to the github sign in page (being logged out)
2. enter some small letters in one of the fields username/password
3. go to the other field password/username
4. activate capslock by swiping to the capslock icon (not by long pressing shift, not by double tapping shift)
5. enter one letter
6. capslock is released automatically

this happens only when activating capslock by swiping to the icon!

this might be related to this: the shift key and the fn key are activted on starting a swipe to the corners (the keyboard flickers shortly). the 123+ key for the numpad is only activted after releasing the tap on 123+.

my guess: a part of the functionally of shift (being released after a single letter) is still active after continuing to swipe to capslock. although this happens only in special cases, which is why the above steps are a way to reproduce this.

preferred solution from a user perspective: activate shift and fn on releasing the tap instead of starting the tap: no flicker, no left over functionality.

[Spike-from-NH]

Caps Lock works fine for me. My best explanation is that Unexpected sensed your gesture as a tap not a swipe, so you didn't get Caps Lock at all. Solutions: ➊ Use it more and learn what you need to do to perform a swipe; or ➋ go into Settings and change the amount of movement that defines a swipe.

Related: ① Shift key darkens when Shift or Caps Lock is active. The legend color changes color to show which one. This indication is too subtle for me; I can't tell at a glance which one is active. RED for Caps Lock? ② Caps Lock cancels if I rub out a typo. This isn't what I want.

[alotbsol555]

capslock works pefectly fine as expected in most cases. the green color indication of the shift key is very helpful to see if it is active. the shift key is green after step 4, which indicates, that capslock was activated by the gesture.

although in some (rare) special cases it is released automatically, often after typing the first letter after entering an empty field. did you try all the steps above? it is not happening in all empty fields! but i can reproduce it consistently with the exact steps above. it also happened in other apps than the browser.

if you stay in the field and type/delete anything, capslock is never again released automaticanly. it is only released automatically when entering an empty field after typing the first letter. that seems suspicous, because that is a functionality of the shift key.

[Spike-from-NH]

Yes, seems like a "feature" of the website rather than of Unexpected, which surely doesn't care what the destination of its output is! I'll let @Julow take the next guess…

[alotbsol555]

you might be right. but i actually spotted the issue in another app and chose the github login page because everyone here has access to that. it would be very strange that the feature would appear only in the second field no matter with which field you start. then it stops appearing in the same field after the first occurance. let's see…

edit, another thought: the issue can not be a feature of the page, because it depends on step 4 (the exact way of activating capslock). i can not imagine the page knowing this.

[Julow]

I fail to reproduce the bug yet but I can see that caps lock is disabled when I delete a character (when first activated with the caps lock button). There seems to be unintended interaction between the caps lock button and auto-capitalisation, though that seems unrelated to your bug that happens in a password field with no auto-capitalisation.

[Julow]

Caps lock can be implemented in a way that do not interfere with auto-capitalisation but it has the weird effect of allowing shift and caps lock to be enabled or locked independently at the same time. Can you try with this debug build? https://github.com/Julow/Unexpected-Keyboard/actions/runs/7941223596

[alotbsol555]

good news: using the debug build capslock is not released automatically as described in this issue!

locking shift and capslock seperately (or both!) is really unexpected if you have ever used a real keyboard. pressing shift should always release all capslocks. personally, i would prefer the regular build, where i removed the capslock key from my layout and started using the double tap on shift.

one more remark on the debug build: when capslock is active after swiping to the capslock key, you have to swipe two times to the capslock key to deactivate it again.

aaand one more thing: this issue here exists also in the username field, not only in the password field. you need to start step 2 in the password field and continue with step 3 in the username field.

[Julow]

Thanks for trying it out! You are right, the fix looks weird and I shouldn't merge it. At least we know where to look for.

[Anarchtism]

This bug also effects the note-taking app Obsidian. I don't mind the strange behavior of the debug build as a tradeoff for it working though because I do quite a lot of typing and text manipulation in Obsidian.

[Julow]

I've found a variant of this bug that I can easily reproduce: Enable caps lock, type "A.", type delete, caps lock is disabled. This should be fixed by 5e5937b.

Can you check whether it fixes your problem ? Debug build: https://github.com/Julow/Unexpected-Keyboard/actions/runs/8131473950

[Anarchtism]

Can you check whether it fixes your problem ? Debug build: https://github.com/Julow/Unexpected-Keyboard/actions/runs/8131473950

Works well for me! Great work.

[alotbsol555]

Can you check whether it fixes your problem ? Debug build: https://github.com/Julow/Unexpected-Keyboard/actions/runs/8131473950

yes! using this debug build, this issue here is gone. thanks again!

[Julow]

Thanks you both for confirming :)