Version: 3.5.6 (using KDE KDE 3.5.6) Installed from: Unspecified Linux I rolled over on my keyboard when I went to bed, and woke up to an alarming number of konqueror windows, with an alarming number of tabs, all containing a particular website. It took a long time to close them all. I'm just thinking that there should be a user sanity check somewhere in these programs. Maybe a "warning, you have 16 windows of this application open, are you sure you want to open another one?" (that is of course user settable to be higher, maybe 32 by default, or even 64) So, this bug is more general than just konqueror, maybe it would be a seporate utility that monitors xwindows, or other application communication methods to catproof KDE. Thanks -AP
What actually happened is that my screen broke, and is pinching the laptop specific buttons, which is interpreted as keystrokes. Really, it should be a part of the UI guideline that holding down a button or key shouldn't break the application or user experience.
I can reproduce this issue. My Lenovo ThinkPad annoyingly has the printscreen key between the right ctrl and alt keys, so I not infrequently find myself accidentally holding it down and then 100 spectacle windows are opened. This is Not Amazing™ and hangs the system prtty bad if enough windows were opened before I noticed. Not sure if this is something that KWin could inhibit, or KGlobalAccel, or the affected app itself. Let's start with KWin.
This isn't the job of the window manager. There's nothing we can sensibly do. The part about launching apps whilst holding down a key is a problem for the spawner
This is bugs.kde.org, not bugs.kwin.org. The spawner is kglobalaccel; re-opening and moving there.
*** Bug 477864 has been marked as a duplicate of this bug. ***
The quickest solution would be to tell app devs to limit the shortcuts within the apps that define the shortcuts, but then every app that naively implements a global shortcut would still have this problem and apps might have slightly different solutions for achieving the same end. Something to consider is how the excessive global shortcut activation are being triggered. In the case of the original report, auto repeat is what causes the issue. Since KGlobalAccel's API uses QActions to register events, maybe we could make something like `action->setAutoRepeat(false)` work? It could make it so you have to release the shortcut sequence keys before it can be triggered again. Auto repeat couldn't be disabled by default since there's no way to determine whether an app dev explicitly set auto repeat on or left it at the default value. At least it wouldn't require every app to implement their own solution. It might not completely solve the problem, but it might solve most issues caused by user input. We could probably rate limit the processing of global shortcuts via timers. However, how long or short the timer should be would probably be highly dependent on the app and what the global shortcut does. There could be a global shortcut that benefits from being able to be activated rapidly (e.g., volume and brightness shortcuts). That once again means apps have to share some responsibility for their behavior. Even 0ms timers might at least help with compressing events created in rapid succession, but probably wouldn't solve the issue. If we went this route, perhaps the behavior could be configurable by app devs with the default being a behavior we generally consider safe?
If there was ever a time when we could get away with changing autoRepeat to false by default, it would be during a major Frameworks version bump, i.e. right now.
This problem was also seen in BUG 483948, as it allowed infinite instances of the shortcut target to be created. The default behaviour should be to filter hold keys, so the filter should be opt-out. It's not trivial to filter it out on the receiving side, as Wayland's security concept implies that you know "a" shortcut was pressed... but not necessarily which one and how. I've experimented with timers, but they're not reliable as they're not accurate and tend to trip. (Remaining time > interval and interval - remaining < 0) It's also not clear what would be a good threshold: I can deliberately spam keys quite fast (e.g. to cycle through elements), which gives me a delta comparable to that of holding down a shortcut.
This wouldn't fix the problem with detecting a hold shortcut though.. it would just prevent spamming it. In my usecase it would be nice to detect if the shortcut was pressed or hold. I don't think the API would allow such a change, without extending it with an event like functionality (like in Qt.KeyEvent).