Red Hat Bugzilla – Bug 1147670
keyboard layout chooser switches letters while typing
Last modified: 2015-05-25 07:13:57 EDT
Description of problem:
while typing to search for my keyboard layout anaconda switches letters.
For example if you type "deu" it will mix up to become "due". This happens while incredibly lagging.
Version-Release number of selected component (if applicable):
F21 Alpha Workstation Live CD
anaconda mixes up letters
anaconda should just accept whatever I type as search term
As far as I can tell, this is a bug in gtk. It seems to happen when typing into the entry box while a TreeFilter refilter operation is still going on. We call refilter on each call to the entry box, and it can sometimes take a while since there's a whole lot of keyboard layouts.
For whatever reason I only see this behavior in the GNOME environment.
*** Bug 1150122 has been marked as a duplicate of this bug. ***
*** Bug 1152786 has been marked as a duplicate of this bug. ***
Please note that bug 1150122 was originally proposed as a blocker, as it concerns a password field (for which you can't even show its contents, at this moment). Also some people reported repeatable difficulties to fill it out. See video attached to bug 1150122 comment 11, frame by frame, for an observable bug confirmation.
a password field with completion ? that sounds like an odd combination to me
The password field does not have completion, but there are some things going on in the changed event to check quality.
Matthias, in short, the typed-in characters sometimes appear in a wrong order (letters swapped) in a text field or a password field. Usually happens under heavy load. Anaconda developers suspect GTK race condition bug. Video attached.
don't see a video attached. And without further details as to why the anaconda developers think GTK+ is to blame, this is a little thin...
(In reply to Matthias Clasen from comment #8)
> don't see a video attached. And without further details as to why the
> anaconda developers think GTK+ is to blame, this is a little thin...
The video is attached to the comment ike kparal says, https://bugzilla.redhat.com/attachment.cgi?id=947273
We think gtk is to blame because anaconda doesn't call set_text during the changed signal, or anywhere. The keyboard monitor shows "fedora" being typed into the password field but it came out "feodra"
so what _does_ anaconda call ? where's the code for your 'changed' handler - what is changing, anyway ? and what is getting filtered ?
Also, the original bug talks about the layout chooser, while the video shows password entries. What gives ? is this a problem you experience with every entry in anaconda ?
Discussed at today's blocker review meeting . Rejected as a blocker, but accepted as a freeze exception. This bug is difficult to reproduce and it seems to be very system-dependant. Accepting as an FE because if you do hit it, it would be pretty obnoxious. Repropose if more solid reproduction steps can be found or there is a concrete system on which it is quite difficult to perform Fedora installation.
Even though we rejected this as a blocker, we would really love to have this fixed. There were people on test list who reported that they couldn't get past the password dialog even though they tried several times. It's very machine-specific, so we can't really say how often this happens. But it has some potential to be quite nasty. If we can't find the root cause, at least some remedy steps would be nice, like including a 'show password' checkbox. If we have that, people will be able to find the swapped letters and correct them, even if usual-speed typing is problematic on their system (please bear in mind that most affected people won't know about this bug, and therefore will not expect swapped letters. Showing the password can help a lot in these cases).
(In reply to Matthias Clasen from comment #10)
> Also, the original bug talks about the layout chooser, while the video shows
> password entries. What gives ?
I have tried to describe it quite extensively in a bug linked from comment 4, which was later duped to this one. Do you need some more details?
> is this a problem you experience with every
> entry in anaconda ?
I have seen this problem mostly in root password field, and a few times in language filter field (but not that often). I have seen several other people reporting this, also in these two areas. I think the common factor is that those are fields where there is heavy activity in the background - filtering languages, or partitioning and usual installation (in case of the root password dialog). Also, I was never able to repeat the bug during the same anaconda run, it always occurred only during the first time that form was opened. (Once I closed and reopened the root password dialog, it didn't happen again).
Quite interestingly, I haven't seen this problem in any other application, just in anaconda. Maybe there's some problem in handling the signals?
Created attachment 957503 [details]
libreport swapped letters
I have seen this problem in libreport as well. I was unable to write a description without a lot of typos, so I recorded it, and it was also affected by this bug. You have to type really fast to trigger it. Attaching sample video. Again, use SMplayer and go frame by frame ('.' shortcut) to verify that I wrote it correctly, but the resulting text has a space and 'o' letter swapped.
In libreport, I was able to easily reproduce this just by typing 'verify' word over and over again. In >20% cases, it ended up mangled.
However, I tried to same with gedit, I tried really hard, and wasn't able to reproduce it. Anaconda and libreport was still running in the background, but no character swapping occurred. So in one text field, it happens, and in a different one, it doesn't (or at least I wasn't able to make it happen).
Is it possible that anaconda does its own background handling of input characters and it affects all fields in it, including libreport window? Because I just don't see it outside of anaconda+libreport.
David, can you point me at the anaconda code for this ?
> so what _does_ anaconda call ? where's the code for your 'changed' handler -
> what is changing, anyway ? and what is getting filtered ?
In the password fields, _updatePwQuality (https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/ui/gui/spokes/password.py#n202) is installed as a changed handler on the first password field. It runs the password through pwquality and updates the GtkLevelBar based on the result. In addition, all of the methods added via add_check() (https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/ui/gui/spokes/password.py#n58) are installed as "changed" handlers. These are lighter-weight, though. They check for empty passwords, non-ASCII passwords, non-matching passwords, and use the result of _updatePwQuality to set info bar messages and update some state variables.
In the keyboard layout selection, typing in the input field calls refilter on the GtkTreeModelFilter (https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/ui/gui/spokes/keyboard.py#n156). The visible-func does a string compare after fiddling with the tree model value a bit to handle translations and diacritics (https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/ui/gui/spokes/keyboard.py#n72). Additionally, the GtkTreeModelFilter's has a GtkTreeModelSort child, which does a localized string compare in its sort-func https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/ui/gui/spokes/keyboard.py#n87
And we don't have anything to do with the libreport window. That's just report-gtk launched via report_problem_in_memory.
are the people who are seeing this problem using any input methods ?
I tried to reproduce the problem locally, but I couldn't convince anaconda or liveinst to come up and accept input in my desktop session. Gave up after ~20 minutes - a reproducer that can be run locally would be very helpful.
In my case (keyboard layout chooser in anaconda, F21 Alpha workstation live cd): I used the F21 alpha without modifications. I just may have selected a different keyboard layout (de-neo/neo2 instead of de).
I saw this in F21 Beta Anaconda, and I directly went to Anaconda (so no input method configuration was done). I went to keyboard layout selection spoke and it brought up the selection window. When I typed the initial letters of my desired layout, the characters appeared out of order. On my (probably considered weak compared to current systems) Intel 1.8 core 2 due cpu, it is very easy to reproduce (actually, I should press keys with long delays to prevent this issue).
So far, no clear picture has emerged here.
There is no code in GTK+ itself that could cause input to be mixed up in this way. GTK+ only emits the changed signal after the input has already been added to the entry.
And I haven't seen code in anaconda that would insert text itself or move the cursor position around (which are things that could cause what you are seeing).
(In reply to Matthias Clasen from comment #16)
> are the people who are seeing this problem using any input methods ?
No input method used even in my case. All defaults confirmed (including English language) and went straight to installation and then the root password field.
One further comment, it seems that everyone affected reported they used a Live image (Hedayat, was it also your case?). It might be specific to just a Live image, and not happening with a DVD/netinst. Or it might not; I'm not having any luck quickly reproducing it today, so I can't say at the moment.
Yes, I also used F21 Workstation live media (since there is no installation media anymore (well, except in Fedora server AFAIK)).
I just tried Beta Live and see ibus seems to be running at least by default.
Today I've found several crasher bugs in anaconda. In almost all the cases, it was quite difficult for me to provide a description in the libreport window. I had to correct several words in every sentence and had to type really slow, otherwise it was full of swapped letters. It seems that it might be easier to reproduce this with libreport than with anaconda itself.
There is a way how to simulate anaconda crash and open the libreport window, it's described here:
I haven't yet tried whether this bug manifests itself using this approach, but I can test it in a while.
I tried causing the fake crash as linked above, but unfortunately I wasn't able to reproduce the letter swapping issue. It seems very random, sometimes it happens, sometimes it doesn't (even when the VM feels laggy, the input event ordering is still kept).
21 is done, cleaning blocker/FE process metadata.
I can reproduce this easily in the F21 anaconda keyboard layout filter
without ibus installed/running.
*** Bug 1176453 has been marked as a duplicate of this bug. ***
Please note that Richard Brown was able to reproduce this issue reliably in bug 1176453 using OpenQA automation. We need to fix this in F22 anaconda.
Kamil, is this still happening with F22?
I haven't reproduced it with F22 Alpha Server netinst in my extremely short testing. But there are some changes, for example anaconda now requires passwords of a certain strength which complicates testing. But we have OpenQA set up now, why don't we try to test it with it? Let's remove the manual delays introduced between the key presses in the root/user password dialog and run it ten or twenty times, and we will see.
Adam or Jan, could you try it? Thanks.
I forgot that OpenQA doesn't test Live at the moment, just netinst. And we haven't seen these issues in netinst, if I read this bug correctly. So I fired up F22 Alpha Workstation Live and tried it 10-15 times manually, and I haven't reproduced this issue. So, we can either wait some time whether someone sees/reports the same problem, or we can close this and reopen in that case.
I've been working on openQA live testing all day and haven't hit this once - lots of other issues, but not this one.
there's no 'artificial delays' in the password code either, that I can see, it just does 'type_string $root_password;' and 'type_string $user_password;'.
In that case I think we can consider this magically fixed. Richard Brown had to introduce manual delays in his script when testing F21:
yeah, I concur, still haven't seen issues with live install testing. We can always re-open if this comes up.
If any reporter is still seeing this bug on F22 live images, please yell and we'll re-open it.