[regression] Ubuntu 18.04 login screen rejects a valid password on first attempt (if starting with Shift key). Usually works on the second attempt

Created attachment 1423716
Journalctl log showing auth failure

Description of problem:
After every reboot the first login attempt fails. At first I assumed I was mistyping the password. Then I started slowly pressing one key at a time to confirm and it still failed. Same pass on all subsequent tries works, even after locking screen.

Version-Release number of selected component (if applicable):
gdm-3.28.1-1.fc28.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Reboot laptop
2. Select User
3. Enter Password
4. Hit Enter or Click button

Actual results:
Login fails on first try

Expected results:
Login succeeds when correct password is entered

Additional info:
This is an upgrade from Fedora 27

Some extra info...

I have noticed that this does actually happen after I lock my screen as well.

I noticed one more possibly important fact. If I type characters (any number of characters) of the password in GDM login screen and then backspace to delete them all... then type in the password and press enter... it works.

So assume my password is 'MyPass!' (hypothetically), I type 'M' then backspace to delete that character then proceed to type 'MyPass!' it will then allow me to log in on the first attempt. Or... I type 'MyPass!' on first attempt (no backspace trick) and it fails... then type 'MyPass!' on second attempt... it works then too.

This seems very much like the first character is somehow entered wrong, but then just the act of deleting it and retyping it, or entering the password a second time it is entered correctly. Maybe libinput issue or similar?

Same here on two different F28 systems.

Proposed as a Blocker for 28-final by Fedora user ddreggors using the blocker tracking app because:

 Fails basic functionality without user intervention. GDM cannot login on first attempt without trying a second time.

Haven't seen this in any of my F28 tests so far.

When you say "Select User", how do you do that exactly?

Also, what keyboard layout do you use?

After reboot there is a list of users. As I'm the only user I just press "enter" after which I'm asked to enter my password.

However, as the same issue also arises after locking the session, I don't think the user selection has anything to do with this.

I use a German keyboard layout.

I can't reproduce this. I tried regular en-US and upgraded from F27 to F28 without any issues. I have also checked it for root/created user across X and Wayland.

Can't reproduce with installation updated from F27 and German keyboard layout.

David, Thomas, this is just a wild guess, but can you try the workaround mentioned in here?
https://fedoraproject.org/wiki/Common_F27_bugs#every-second-login-fails

I.e. try to use X11 session instead of Wayland session, and see if "auto-save-session" value is true or not. Thanks.

Well I have somewhat similar thing to report here. Since I upgraded to Fedora 28, whenever screen gets locked out and I return back to unlock it, my first attempt after entering correct password fails (I kept blaming myself for wrong developed muscle memory) but after seeing this bug, I thought to report here.

This is consistent for me. The first attempt to unlock screen failed most times(may be I can say it always failed). But second attempt always succeeds.

I also already have gsettings get org.gnome.SessionManager auto-save-session -> false.

Can't reproduce this on any of my F28 systems.

I cannot reproduce this either.

I'm inclined to vote -1 blocker on the following grounds:
1) Once this is identified, it can be resolved with an update
2) Most users would default to assuming they'd mistyped the first time and re-enter their password.

-1 blocker for reasons Stephen notes (along with "can't reproduce" comments).

Those who experience the bug, can you right click on the password field and click "Show Text" (or whatever it is in your language) after entering the password for the first time to see if that matches what you're typing?

(In reply to J. Haas from comment #15)
> Those who experience the bug, can you right click on the password field and
> click "Show Text" (or whatever it is in your language) after entering the
> password for the first time to see if that matches what you're typing?

Interesting... it appears to ignore the shift-key, i.e. a small letter is always entered.

Theory: Everybody who was not able to reproduce this uses a small letter at the beginning of his/her password?

(In reply to Thomas Müller from comment #16)
> (In reply to J. Haas from comment #15)
> > Those who experience the bug, can you right click on the password field and
> > click "Show Text" (or whatever it is in your language) after entering the
> > password for the first time to see if that matches what you're typing?
>
> Interesting... it appears to ignore the shift-key, i.e. a small letter is
> always entered.
>
> Theory: Everybody who was not able to reproduce this uses a small letter at
> the beginning of his/her password?

I can actually now reproduce this (and yes, the shift is initially ignored) when attempting to enter a password for my GPG key using the GNOME askpass dialog (starts with a capital letter).

So I'd say the above theory seems likely. That's... quite a catch.

I'm still -1 blocker on it for the reasons above, but we should try to fix this as quickly as possible.

Are there any use cases where the askpass dialog is also used to set a *new* password somewhere?
If yes and the same behavior applies there users are going to be frustrated if they can't use their password later on as the first letter is not what they would expect it to be.

Thanks J. Haas, I also confirm its an issue with shift key. It ignores shift-key usage at the first time and if I backspace before completing password and retype my password, it works.

I still can't reproduce this in a fresh install to a VM, FWIW. I installed from the RC-1.1 Workstation live, created user Test with password Test in gnome-initial-setup on first boot, and was able to log in first time both on the initial appearance of GDM after g-i-s was complete, and after a reboot. The 'show text' option shows that I truly did type 'Test'.

Stephen, how did you reproduce this exactly?

Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see that one but not the GDM one.

(In reply to Adam Williamson from comment #21)
> Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see
> that one but not the GDM one.

Yeah, I was about to say that: I can repro it on lock screen and askpass, but I didn't see it happen at GDM. Not sure why.

My running hypothesis is that we inherited this with the gtk3 rebase we pulled in for FE, since I am pretty sure I didn't see it before I updated yesterday (and I have had the -testing repos disabled since we entered Freeze).

"Are there any use cases where the askpass dialog is also used to set a *new* password somewhere?"

The only case I can think of where it might happen is timed password expiry, we could test that.

-1 blocker, this can be fixed post-release

(In reply to Adam Williamson from comment #23)
> "Are there any use cases where the askpass dialog is also used to set a
> *new* password somewhere?"
>
> The only case I can think of where it might happen is timed password expiry,
> we could test that.

Adam: I think this would already be covered by automated testing for https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_password_change or am I mistaken?

I'm definitely reconsidering my -1. If we can verify that it's just the first attempt and just the lockscreen/askpass, a zero-day would probably be okay.

I'll weight Michael Catanzaro and other Workstation team members' opinions on this heavily — if they're not going to be embarrassed, I'll try not to be. :)

I can verify that this also happens in the "create keyring" dialog in Seahorse when setting a password for the keyring. It's not a huge problem, as you need to enter the password twice and the problem only happens in the topmost password box, but it's definitely annoying.

I've actually seen this about a year ago.

I had upgraded from Fedora Workstation 26 to 27. I don't remember whether this happened to me before the upgrade, but it certainly happened after.

I remember that it was happening a bit before GUADEC, so I'd figure I'd try and find someone there to fix it.

It stopped happening right before GUADEC, when I reinstalled my machine. (the day I was supposed to take the plane, I run an unfortunate `rm -rf /` and had to reinstall and restore my data from backup)

So I guess this isn't a recent regression, but something old which just doesn't happen for most people?

(In reply to Matthew Miller from comment #26)
> I'm definitely reconsidering my -1. If we can verify that it's just the
> first attempt and just the lockscreen/askpass, a zero-day would probably be
> okay.
>
> I'll weight Michael Catanzaro and other Workstation team members' opinions
> on this heavily — if they're not going to be embarrassed, I'll try not to
> be. :)

I think we should try to fix it ASAP, of course. But if we have a zero-day update, then users will hopefully only hit this bug once or twice at most, in which case they probably won't even notice.

(In reply to J. Haas from comment #27)
> I can verify that this also happens in the "create keyring" dialog in
> Seahorse when setting a password for the keyring. It's not a huge problem,
> as you need to enter the password twice and the problem only happens in the
> topmost password box, but it's definitely annoying.

OK, that changes everything. I have two thoughts on this:

 (a) Most of seahorse is already super broken and has been for a long time, that's why we don't install it anymore
 (b) That's a GTK+ dialog

(b) is very significant because up until now, all the reported password entries were gnome-shell: that's why I reassigned the bug to gnome-shell. Now you're saying this affects GTK+ as well, right? I just tested with seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse itself, not the black overlay that gnome-shell draws when it asks for your password? That's *really* seriously weird; it's hard to imagine what could break password entry in two unrelated toolkits. Maybe ibus?

(In reply to Michael Catanzaro from comment #29)
> (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore

(BTW please keep this in mind: seahorse is no longer on the live image. We actually had a presentation at GUADEC a couple years ago that was all about how almost all of the menu items and dialogs were broken. Please don't consider seahorse at all when making a blocker determination.)

Created attachment 1427284
Seahorse screenshot

I'm not sure Seahorse uses a GTK+ dialog, it draws the black shadow and so on.

Here I entered "Test" in both password boxes, but it ignored the first shift key press.

(In reply to Michael Catanzaro from comment #29)
> (In reply to Matthew Miller from comment #26)
> > I'm definitely reconsidering my -1. If we can verify that it's just the
> > first attempt and just the lockscreen/askpass, a zero-day would probably be
> > okay.
> >
> > I'll weight Michael Catanzaro and other Workstation team members' opinions
> > on this heavily — if they're not going to be embarrassed, I'll try not to
> > be. :)
>
> I think we should try to fix it ASAP, of course. But if we have a zero-day
> update, then users will hopefully only hit this bug once or twice at most,
> in which case they probably won't even notice.
>
> (In reply to J. Haas from comment #27)
> > I can verify that this also happens in the "create keyring" dialog in
> > Seahorse when setting a password for the keyring. It's not a huge problem,
> > as you need to enter the password twice and the problem only happens in the
> > topmost password box, but it's definitely annoying.
>
> OK, that changes everything. I have two thoughts on this:
>
> (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore
> (b) That's a GTK+ dialog
>
> (b) is very significant because up until now, all the reported password
> entries were gnome-shell: that's why I reassigned the bug to gnome-shell.
> Now you're saying this affects GTK+ as well, right? I just tested with
> seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse
> itself, not the black overlay that gnome-shell draws when it asks for your
> password? That's *really* seriously weird; it's hard to imagine what could
> break password entry in two unrelated toolkits. Maybe ibus?

I just tested this and it is NOT using the GTK+ dialog, it's using the GNOME Shell dialog. I'm not sure when that changed, but I hope that information is less alarming.

(In reply to J. Haas from comment #31)
> Created attachment 1427284 [details]
> Seahorse screenshot
>
> I'm not sure Seahorse uses a GTK+ dialog, it draws the black shadow and so
> on.
>
> Here I entered "Test" in both password boxes, but it ignored the first shift
> key press.

Yeah, that's the gnome-shell prompt. OK, less alarming indeed.

Well, still bad, but more understandable.

You actually kinda can reproduce this outside of gnome-shell password prompts. If you manage to exit a gnome-shell password prompt while a standard GTK textfield already is focused, and then you try to directly type uppercase text, it will ignore the shift key press.

You can easily reproduce that with the Seahorse dialog I took a screenshot of, but I also managed to reproduce it with a password prompt in Nautilus.

This also appears to affect the "unlock" dialog in Gnome Control Panel, for what it's worth.

(In reply to Adam Williamson from comment #6)
> Also, what keyboard layout do you use?

Sorry I just saw this, I use English (US) keyboard layout. Also, by select user I meant on GDM login screen where you see your user (or others if they exist), I click myself if not already highlighted.

I added this info late I know, it seems there has been much movement on this bug and much has been discovered. Again, sorry for late reply.

(In reply to Thomas Müller from comment #16)
> (In reply to J. Haas from comment #15)
> > Those who experience the bug, can you right click on the password field and
> > click "Show Text" (or whatever it is in your language) after entering the
> > password for the first time to see if that matches what you're typing?
>
> Interesting... it appears to ignore the shift-key, i.e. a small letter is
> always entered.
>
> Theory: Everybody who was not able to reproduce this uses a small letter at
> the beginning of his/her password?

To confirm, I do use a capital letter as first character.

I would like to also remind all here that I was able to backspace after typing first character on first login attempt, then retype it and the shift key works (capital letter is entered this time).

This also affects other modifiers - I've just realized, because it affects pasting passwords into the password prompt :( This will affect everyone who uses a password manager, when they go to enter e.g. an ssh key via the ssh-askpass integration. Hitting 'ctrl-v' just gives you a 'v'. Just like with the 'shift' case, hitting backspace and then ctrl-v again works, or it works on the second attempt.

I cannot reproduce the problem.
Did you install the latest mutter & gnome-shell?

Lots of people have reproduced this so far, I don't think it's plausible to claim that the bug doesn't exist at this point. Yes, everyone is testing with the latest gnome-shell and mutter, in fact we think 3.28.1 actually *introduced* this bug. Multiple GNOME devs have already reproduced this and are discussing how to fix it, e.g. in this log from #fedora-desktop:

<garnacho> https://gitlab.gnome.org/GNOME/mutter/merge_requests/97 is for the password thing btw, root cause pending, but that's enough to fix it
<halfline> garnacho: nice
<halfline> hmm
<halfline> so that code got added here it seems: https://bugzilla.gnome.org/show_bug.cgi?id=725102
<halfline> and in that bug it says this: "switching the keymap
<halfline> should be done at a time when no key is currently pressed down, but let's leave that task to higher level code"
<garnacho> yeah, quite fishy that it changes while typing stuff, it's clearly not due to the focus change
<halfline> it's the same keymap again ?
<garnacho> in essence yes
<garnacho> maybe some explicit keymap change to cater for per-window IM -> clutter focus changes?
<garnacho> I guess that mention in the code is there for the situations where you shuffle modifier keys around
<garnacho> but hardly stands true with <super>space :/
<garnacho> s/in the code/in the bug/
<halfline> well your patch makes sense to me on the surface. i wish rtcm was here
<halfline> i wonder if it's from InputSourceManager's _keyboardOptionsChanged or from activateInputSource
<halfline> i guess if activating the input source is async and it happens on focus in that might explain it
* halfline tries adding some logs
<garnacho> halfline: not sure it's simply that. I've been trying with a polkit dialog, and took my time before typing
<garnacho> it's somehow sent around the same time shift is pressed
<garnacho> but yeah, ideally the keymap shouldn't even change :)
<halfline1> i was working on adding some backtrace dumpping to InputSource activate but had to run to a meeting

(In reply to Adam Williamson from comment #40)
> Lots of people have reproduced this so far, I don't think it's plausible to
> claim that the bug doesn't exist at this point. Yes, everyone is testing
> with the latest gnome-shell and mutter, in fact we think 3.28.1 actually
> *introduced* this bug.

FWIW, 3.28.1 *re*introduced this bug, because 3.28.0 had other bug that prevented this in the first place on the most common setups. This seems to stem in untimely changes to the org.gnome.desktop.input-sources.sources dconf key that reset current modifier state.

My wild guess is that those actually come from ibus, but gnome-shell can protect itself from those, I opened https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/91 about it.

gnome-shell-3.28.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398

I backported the fix to Rawhide and F28 and submitted an update for F28. Thanks, Carlos. Can folks affected by this test and see if the update fixes it for you? Thanks!

So far gnome-shell-3.28.1-3.fc28 is looking good. :)

This does not yet appear in updates-testing, should it?

(In reply to David Dreggors from comment #45)
> This does not yet appear in updates-testing, should it?

Not yet. There will be an automated comment on this bug when it reaches testing.

In the meantime you can download it direct from Koji for testing, the update page has a link through to the Koji build - https://koji.fedoraproject.org/koji/buildinfo?buildID=1077605

Discussed during F28 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-04-26/f28-final-go-no-go-meeting.2018-04-26-17.02.txt . It was generally felt that, while this is clearly a serious bug, it's not actually going to significantly inconvenience people during install boot and install of Workstation: even if they hit it they'll likely just assume they mis-typed, and type their password again, and it will work. Beyond that, it can be fixed with an update. Thus, this was rejected as a blocker.

gnome-shell-3.28.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398

gnome-shell-3.28.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

I am still seeing this or a related bug. With gnome-shell 3.28.1-3.fc28 installed, every text I type is using the english (US) keyboard layout in gdm, no matter what keyboard layout I configured. Switching the layout at runtime does not change anything. I have 3 layouts configured (de: neo, de: nodeadkeys, us). GDM always uses the last one no matter which one I configure.

On any tty and within any Gnome session, keyboard layouts behave correctly, using the default de:neo keyboard layout.

This looks like bug #1573923 to me.

(In reply to Christian Stadelmann from comment #51)
> This looks like bug #1573923 to me.

I think the fix for this bug introduced that one.

Yes. If you choose "Show Text" in the right-click menu, it shows that the first letter was entered as a lowercase letter.