Bug 1150122

Description of problem:
Recently I've started noticing that my root password is very often not accepted by anaconda, because "the fields don't match". It happened way too often for me to become suspicious. Then Vratislav Podzimek told me he started seeing the same. Then Corey McLaughlin confirmed the same experience on test list:
https://lists.fedoraproject.org/pipermail/test/2014-October/123080.html

The biggest roadblock when debugging this issue is that anaconda does not allow the user to display his/her own provided password (something like "Show password" check box). So it's very hard to say whether it's a bug in anaconda/gtk, or my fingers.

Finally I recorded a video with a keyboard monitor overlayed over the VM. If you use a movie player capable to going frame by frame (smplayer works very well, use '.' to advance by frames), you can see that I really input the same password ('fedora') into both fields, but they "don't match". I don't really know what's in them (once again, my rant about missing "show password" check box), but if I replace the characters one by one, I finally find one (or at least one) which was incorrect and then the passwords match.

The timing is extremely important to trigger this bug. It is a race condition, I believe, and you have to be very fast. I was only able to trigger this bug on the first time I entered Root Password spoke. No subsequent entry triggered the bug. Also, the first time I enter it, I need to start typing _immediately_. My theory is that the form is not fully initialized by the time it is displayed, and when I start typing immediately, it fully initialized in the mean time (after I started typing and before I finished typing). And that breaks the input for one or more characters.

It's very interesting that when testing this in VM, usually the first password is broken, the first or the second character. Once I replace it, the fields match. But when I had screen recording active, it was always the second password, usually the last but one character. That again seems to indicate that it's a race condition and you need to hit some kind of a time window. When my host CPU was more busy, the problem occurred later. Maybe if I hogged the CPU even more, I'd type down both passwords before the "buggy window" had even started. Which also means that you might be able to hit this problem even if you are not lightning fast with your finger, provided that you have slow enough machine (single core, perhaps?).

I believe I did the same problem even on bare metal, not just VM. But on bare metal I don't have any convenient keylogger installed, so I wasn't able to verify this (sure, I could install it if it's really needed).

It seems the problem might be caused both by anaconda or gtk. I don't know which one, but I'm fully sure it did not happen in F20. It might even not have happened with early F21 composes, if really necessary, I can burn a lot of time, go one by one, and test them. It's very time consuming, though.

I think the best step forward would be to add "show password" checkbox to both Root and User spokes (I assume User spoke is affected as well, you just can't reach the password fields soon enough to hit the race. The checkbox would still be useful, though). After we are able to display the actual contents of the fields, we can then find out what got wrong with the input and debug it further.

Version-Release number of selected component (if applicable):
anaconda 21.48.7-1
gtk2-2.24.24-3.fc21.x86_64
gtk3-3.14.0-1.fc21.x86_64
gnome-shell-3.14.0-2.fc21.x86_64

How reproducible:
quite often on my laptop, probably difficult on other computers (race condition)

Steps to Reproduce:
1. start the installation
2. click into Root Password dialog and IMMEDIATELY
3. start typing password, hit Tab, type the password again
4. if you were affected by the race, the fields won't match
5. wish for 'show password' checkbox