Launchpad has imported 44 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1569211.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2018-04-18T19:45:34+00:00 David wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/0 ------------------------------------------------------------------------ On 2018-04-21T00:38:09+00:00 David wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/6 ------------------------------------------------------------------------ On 2018-04-25T04:34:08+00:00 Thomas wrote: Same here on two different F28 systems. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/14 ------------------------------------------------------------------------ On 2018-04-26T02:29:05+00:00 Fedora wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/15 ------------------------------------------------------------------------ On 2018-04-26T03:42:58+00:00 Adam wrote: Haven't seen this in any of my F28 tests so far. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/16 ------------------------------------------------------------------------ On 2018-04-26T03:43:45+00:00 Adam wrote: When you say "Select User", how do you do that exactly? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/17 ------------------------------------------------------------------------ On 2018-04-26T03:45:39+00:00 Adam wrote: Also, what keyboard layout do you use? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/18 ------------------------------------------------------------------------ On 2018-04-26T04:39:35+00:00 Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/19 ------------------------------------------------------------------------ On 2018-04-26T06:18:55+00:00 sumantro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/21 ------------------------------------------------------------------------ On 2018-04-26T08:00:23+00:00 J. wrote: Can't reproduce with installation updated from F27 and German keyboard layout. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/22 ------------------------------------------------------------------------ On 2018-04-26T08:53:47+00:00 Kamil wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/23 ------------------------------------------------------------------------ On 2018-04-26T11:17:18+00:00 Parag wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/24 ------------------------------------------------------------------------ On 2018-04-26T11:48:03+00:00 Paul wrote: Can't reproduce this on any of my F28 systems. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/25 ------------------------------------------------------------------------ On 2018-04-26T12:30:59+00:00 Stephen wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/26 ------------------------------------------------------------------------ On 2018-04-26T13:11:28+00:00 Matthew wrote: -1 blocker for reasons Stephen notes (along with "can't reproduce" comments). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/27 ------------------------------------------------------------------------ On 2018-04-26T14:30:33+00:00 J. wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/28 ------------------------------------------------------------------------ On 2018-04-26T14:45:18+00:00 Thomas wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/29 ------------------------------------------------------------------------ On 2018-04-26T15:00:29+00:00 Stephen wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/30 ------------------------------------------------------------------------ On 2018-04-26T15:07:03+00:00 Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/31 ------------------------------------------------------------------------ On 2018-04-26T15:21:17+00:00 Parag wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/32 ------------------------------------------------------------------------ On 2018-04-26T15:23:04+00:00 Adam wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/33 ------------------------------------------------------------------------ On 2018-04-26T15:24:04+00:00 Adam wrote: Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see that one but not the GDM one. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/34 ------------------------------------------------------------------------ On 2018-04-26T15:25:42+00:00 Stephen wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/35 ------------------------------------------------------------------------ On 2018-04-26T15:26:20+00:00 Adam wrote: "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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/36 ------------------------------------------------------------------------ On 2018-04-26T15:28:17+00:00 Michael wrote: -1 blocker, this can be fixed post-release Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/37 ------------------------------------------------------------------------ On 2018-04-26T15:29:04+00:00 Stephen wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/38 ------------------------------------------------------------------------ On 2018-04-26T15:30:37+00:00 Matthew wrote: 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. :) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/39 ------------------------------------------------------------------------ On 2018-04-26T15:37:27+00:00 J. wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/40 ------------------------------------------------------------------------ On 2018-04-26T15:42:07+00:00 Mathieu wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/41 ------------------------------------------------------------------------ On 2018-04-26T15:48:19+00:00 Michael wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/42 ------------------------------------------------------------------------ On 2018-04-26T15:50:28+00:00 Michael wrote: (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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/43 ------------------------------------------------------------------------ On 2018-04-26T15:52:58+00:00 J. wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/44 ------------------------------------------------------------------------ On 2018-04-26T15:55:22+00:00 Stephen wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/45 ------------------------------------------------------------------------ On 2018-04-26T16:02:11+00:00 Michael wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/46 ------------------------------------------------------------------------ On 2018-04-26T16:34:52+00:00 J. wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/47 ------------------------------------------------------------------------ On 2018-04-26T18:48:26+00:00 Jared wrote: This also appears to affect the "unlock" dialog in Gnome Control Panel, for what it's worth. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/48 ------------------------------------------------------------------------ On 2018-04-27T17:47:46+00:00 David wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/49 ------------------------------------------------------------------------ On 2018-04-27T17:53:02+00:00 David wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/50 ------------------------------------------------------------------------ On 2018-04-27T20:55:46+00:00 Adam wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/51 ------------------------------------------------------------------------ On 2018-04-27T21:56:13+00:00 fujiwara wrote: I cannot reproduce the problem. Did you install the latest mutter & gnome-shell? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/52 ------------------------------------------------------------------------ On 2018-04-27T22:05:38+00:00 Adam wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/53 ------------------------------------------------------------------------ On 2018-04-29T15:15:36+00:00 Carlos wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/55 ------------------------------------------------------------------------ On 2018-04-29T23:25:57+00:00 Fedora wrote: gnome-shell-3.28.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/57 ------------------------------------------------------------------------ On 2018-04-29T23:27:16+00:00 Adam wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1765261/comments/58 ** Changed in: gnome-shell (Fedora) Status: Unknown => Fix Committed ** Changed in: gnome-shell (Fedora) Importance: Unknown => Medium ** Bug watch added: GNOME Bug Tracker #725102 https://bugzilla.gnome.org/show_bug.cgi?id=725102 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1765261 Title: [regression] Ubuntu 18.04 login screen rejects a valid password on first attempt. Usually works on the second attempt To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1765261/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
