Bug 292010 - Keys with modifiers don't trigger "keyboard input blocked" red flash
Summary: Keys with modifiers don't trigger "keyboard input blocked" red flash
Status: CONFIRMED
Alias: None
Product: yakuake
Classification: Applications
Component: general (other bugs)
Version First Reported In: 2.9.8
Platform: Debian testing Linux
: NOR minor
Target Milestone: ---
Assignee: Eike Hein
URL:
Keywords: investigated
Depends on:
Blocks:
 
Reported: 2012-01-20 04:08 UTC by Nicolás Alvarez
Modified: 2021-03-10 20:37 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolás Alvarez 2012-01-20 04:08:46 UTC 
When keyboard input is disabled on a yakuake tab, pressing a key causes the terminal to briefly flash red to remind the user that input is disabled. The red flash doesn't happen with numpad keys. The only numpad key that causes the flash is numlock toggle.
Comment 1 Nicolás Alvarez 2012-01-20 06:09:35 UTC 
I just found that Ctrl-<letter> key presses don't cause a red flash either.

This *might* be a separate issue, but can't really tell without tracking down the cause for both.
Comment 2 Nicolás Alvarez 2012-02-13 01:49:56 UTC 
Turns out *any* modifier key makes the red flash stop happening. Wonder how I didn't notice that before, especially for Shift.

Terminal::eventFilter is explicitly checking for modifiers in the key press event and only emits keyboardInputBlocked if there are no modifiers set. In addition, keys in the numpad have modifiers() == KeypadModifier.
Comment 3 Justin Zobel 2021-03-09 07:25:42 UTC 
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 4 Nicolás Alvarez 2021-03-10 20:37:21 UTC 
I confirm this bug still exists.