Bug 1147670 - keyboard layout chooser switches letters while typing
keyboard layout chooser switches letters while typing
Product: Fedora
Classification: Fedora
Component: gtk3 (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: 1150122 1152786 1176453 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2014-09-29 15:42 EDT by Christian Stadelmann
Modified: 2015-05-25 07:13 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-03-23 16:52:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
libreport swapped letters (272.39 KB, application/ogg)
2014-11-14 05:27 EST, Kamil Páral
no flags Details

  None (edit)
Description Christian Stadelmann 2014-09-29 15:42:29 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

How reproducible:

Actual results:
anaconda mixes up letters

Expected results:
anaconda should just accept whatever I type as search term
Comment 1 David Shea 2014-10-09 16:20:10 EDT
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.
Comment 2 David Shea 2014-10-15 09:28:25 EDT
*** Bug 1150122 has been marked as a duplicate of this bug. ***
Comment 3 David Shea 2014-10-15 09:28:28 EDT
*** Bug 1152786 has been marked as a duplicate of this bug. ***
Comment 4 Kamil Páral 2014-10-15 13:03:42 EDT
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.
Comment 5 Matthias Clasen 2014-10-16 10:48:30 EDT
a password field with completion ? that sounds like an odd combination to me
Comment 6 David Shea 2014-10-16 12:48:03 EDT
The password field does not have completion, but there are some things going on in the changed event to check quality.
Comment 7 Kamil Páral 2014-10-20 10:32:17 EDT
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.
Comment 8 Matthias Clasen 2014-11-11 10:41:33 EST
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...
Comment 9 David Shea 2014-11-11 11:50:18 EST
(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"
Comment 10 Matthias Clasen 2014-11-12 11:50:22 EST
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 ?
Comment 11 Kamil Páral 2014-11-12 12:48:15 EST
Discussed at today's blocker review meeting [1]. 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).

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-12/
Comment 12 Kamil Páral 2014-11-12 12:56:18 EST
(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?
Comment 13 Kamil Páral 2014-11-14 05:27:59 EST
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.
Comment 14 Matthias Clasen 2014-11-14 06:40:17 EST
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 ?
Comment 15 David Shea 2014-11-14 09:11:49 EST
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.
Comment 16 Matthias Clasen 2014-11-14 13:59:46 EST
are the people who are seeing this problem using any input methods ?
Comment 17 Matthias Clasen 2014-11-14 14:14:56 EST
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.
Comment 18 Christian Stadelmann 2014-11-14 18:48:19 EST
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).
Comment 19 Hedayat Vatankhah 2014-11-15 13:39:06 EST
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).
Comment 20 Matthias Clasen 2014-11-15 14:45:57 EST
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).
Comment 21 Kamil Páral 2014-11-18 05:05:41 EST
(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.
Comment 22 Hedayat Vatankhah 2014-11-18 11:27:34 EST
Yes, I also used F21 Workstation live media (since there is no installation media anymore (well, except in Fedora server AFAIK)).
Comment 23 Jens Petersen 2014-11-19 02:31:17 EST
I just tried Beta Live and see ibus seems to be running at least by default.
Comment 24 Kamil Páral 2014-11-19 10:11:11 EST
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.
Comment 25 Kamil Páral 2014-11-20 04:39:08 EST
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).
Comment 26 Adam Williamson 2014-12-05 14:46:46 EST
21 is done, cleaning blocker/FE process metadata.
Comment 27 Jens Petersen 2014-12-18 01:56:32 EST
I can reproduce this easily in the F21 anaconda keyboard layout filter
without ibus installed/running.
Comment 28 Kamil Páral 2014-12-22 04:49:49 EST
*** Bug 1176453 has been marked as a duplicate of this bug. ***
Comment 29 Kamil Páral 2014-12-22 04:51:37 EST
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.
Comment 30 Adam Williamson 2015-03-09 22:57:44 EDT
Kamil, is this still happening with F22?
Comment 31 Kamil Páral 2015-03-10 09:08:53 EDT
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.
Comment 32 Kamil Páral 2015-03-11 07:21:44 EDT
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.
Comment 33 Adam Williamson 2015-03-11 08:52:17 EDT
I've been working on openQA live testing all day and haven't hit this once - lots of other issues, but not this one.
Comment 34 Adam Williamson 2015-03-11 08:53:40 EDT
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;'.
Comment 35 Kamil Páral 2015-03-11 09:13:41 EDT
In that case I think we can consider this magically fixed. Richard Brown had to introduce manual delays in his script when testing F21:
Comment 36 Adam Williamson 2015-03-23 16:52:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.