Red Hat Bugzilla – Bug 559949
Keystrokes appear backwards under load
Last modified: 2010-08-25 22:09:17 EDT
Description of problem:
When the system is under high load (i.e. when the appearance of typed characters lags behind the actual typing) the queued up characters appear in reverse order when typing in (for example) kate.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open kate with a large file (3.5 MiB seems to be enough on my computer)
2. Bring up the search bar (ctrl+f) and select option "highlight all"
3. Start search with a character that occurs many times in the document to trigger the highlighting. Continue typing fast enough that the typed text doesn't show up immediately in the search field.
When the search is done, the text typed while kate is busy appears in reverse order (i.e. hello comes out as "holle".)
Typed text comes out in the order typed.
I first noticed this when I enabled ibus as input methods (System -> preferences -> input method -> enable input method feature, "Use IBus (Recommended)"), which is why this is reported on the ibus package.
It is easily reproduced using kate for me (probably because of how its search function is implemented), but this happens sometimes in other apps too when the system is sluggish.
Does it still happen with ibus-1.3.x
(In reply to comment #1)
> Does it still happen with ibus-1.3.x
Yes, same behavior with:
I tried this but kate is frozen even if I disable ibus.
% head test.txt
% wc -l test.txt
% ls -l test.txt
-rw-rw-r-- 1 f f 3680000 2010-06-28 12:35 test.txt
Probably I think your text file is needed to reproduce the problem.
(In reply to comment #3)
> I tried this but kate is frozen even if I disable ibus.
Yes, that's expected. The difference would be that when kate finally unfreezes, the typed text appears backwards when using ibus and correctly when ibus is disabled.
> % head test.txt
> % wc -l test.txt
> 73600 test.txt
> % ls -l test.txt
> -rw-rw-r-- 1 f f 3680000 2010-06-28 12:35 test.txt
> Probably I think your text file is needed to reproduce the problem.
Unfortunately, I no longer have access to that text file (but it happened with several different large log files), nor to the computer exhibiting the problem.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to comment #4)
> Unfortunately, I no longer have access to that text file (but it happened with
> several different large log files), nor to the computer exhibiting the problem.
If you could send the big file, please reopen the bug.
Currently I have no idea to reproduce your problem.