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
Desktop Bugs, which is subscribed to gnome-shell in 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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

Reply via email to